Ci on Micha Kops' Tech Notes

CVE Scanning and Guided Remediation with OSV Scanner

Fri, 28 Mar 2025 00:00:00 +0100

Figure 1. OSV Scanner

Security is a critical aspect of software development, and staying ahead of vulnerabilities is essential for us application developers. Google’s OSV Scanner is a powerful tool that helps detect vulnerabilities in open-source dependencies.

This article will guide us through setting up and using OSV Scanner to secure our projects, scan for invalid licenses, scan OCI images and finally how to fix findings via guided remediation.

Whitesource Snippets

Sun, 11 Nov 2018 00:00:00 +0100

Whitesource Configuration for GitLab Pipeline

The following configuration derives values from predefined GitLab Variables

whitesource.conf

# Providing project information from GitLab CI
wss_project_name="$CI_PROJECT_NAME"
wss_project_version="$CI_JOB_ID"
wss_project_tag="$CI_COMMIT_TAG"

# Providing product information
wss_product_name="The Product Name"
wss_product_version="$POM_VERSION"

# Analyze the Maven POM and its transitive dependencies only, no file-system check
# Use this only if you don't have any extra checked in jar-files or stuff like that!
fileSystemScan=false
includes=pom.xml

# Only scanning the Maven project
resolveAllDependencies=false
maven.resolveDependencies=true

Continuous Delivery with GitHub Cloud and GitHub Pipelines

Fri, 01 Jul 2016 00:00:00 +0200

Atlassian has added a continuous integration service as a new feature to their GitHub Cloud product. It’s called GitHub Pipelines and it is similar to Travis CI for GitHub offering a nice integration for continuous integration/delivery pipelines for projects hosted on GitHub.

It’s still in the beta phase and requires a sign-up but nevertheless I’d like to demonstrate the current state of this service and how easy it is to add scripted pipelines to a project.

Mutation Testing with Pitest and Maven

Sun, 10 May 2015 00:00:00 +0200

Mutation testing makes an interesting addition to the classical test coverage metrics.

They seed mutations (errors) into the code, run the project’s tests afterwards and if the tests fail, the mutation is killed – otherwise it lived and we have a possible indication of an issue with our tests.

In the following short tutorial. I’d like to demonstrate how to setup mutation tests with the PIT/Pitest library and Maven and generate reports.

Allocating available random Ports in a Maven Build

Wed, 07 May 2014 00:00:00 +0200

Recently in a project I encountered the following problem: The development team used Git with a branch-per-feature-like workflow and the integration server, Bamboo in this case, was configured not only to run the integration-tests for the master-branch but also for every change in a feature branch.

As the team developed a Java EE web application ports like 8080 occasionally were already bound and builds failed.

I knew a plug-in for Jenkins CI I to search for available ports and assign them to a build variable but I wanted to control such information directly within the Maven build life-cycle so I searched and finally found Sonatype’s Port Allocator Plug-in for Maven.

GitHub Snippets

Mon, 01 Mar 2010 00:00:00 +0100

GitHub Actions

Step to check variables and redistribute as env

The following step does ..

check of given variables are set, if not, exit with an error that is visible in the action’s log
provide the given input as environment variable in GITHUB_ENV

- name: configuration
      env:
        VAR1: ${{ needs.configure.outputs.something }}
        VAR2: ${{ vars.SOMETHING_OTHER }}/
        VAR3: "something_other_other"
      run: |
        for var in VAR1 VAR2 VAR3; do [ -n "${!var}" ] || { echo "$var is missing"; exit 1; }; echo "$var=${!var}" >> "$GITHUB_ENV"; done

GitLab Snippets

Mon, 01 Mar 2010 00:00:00 +0100

Generate AsciiDoc Documentation and Publish it with GitLab Pages

We setup a repository and add a directory named docs there .. this is the home of our AsciiDoc files.

We’re using asciidoctor/docker-asciidoctor as Docker image for tool provisioning

This is the .gitlab-ci.yml, we’re running the stage only when something in the docs directory has changed.

stages:
  - "Build docs"

# The name of the job activates the GitLab pages publication
pages:
  image: asciidoctor/docker-asciidoctor
  stage: "Build docs"
  tags:
    - build
  script:
    - sh ./gen_docs.sh
    - mv output public
  only:
    refs:
      - master
    changes:
      - /docs/*
  artifacts:
    paths:
      - public
    expose_as: 'Documentation Archive'