If built-in License Management functionality does not support the programming language requirements you have, you can customize the License Management docker image.

This guide shows you how to use License Management with OpenJDK 11 or later.

License Management definition

License Management helps you find what licenses your project uses in its dependencies and decide for each of then whether to allow it or forbid it.

License Management reports generation

According to the GitLab documentation you can take advantage of License Management by adding a license_management job to your .gitlab-ci.yml file.

Warning

Please note license_management will append a licenseFinder task to your existing gradle file. This is not possible if you use the gradle plugins block (plugins {...}) which must be a top level statement in the buildscript.

Example build.gradle file:

// spring boot sample project, see: https://spring.io/guides/gs/spring-boot/
buildscript {
    repositories {
        jcenter()
        maven { url "https://plugins.gradle.org/m2/" }
    }
    dependencies {
        classpath("org.springframework.boot:spring-boot-gradle-plugin:2.1.1.RELEASE")
        // required license plugin
        classpath("gradle.plugin.nl.javadude.gradle.plugins:license-gradle-plugin:0.14.0")
    }
}

apply plugin: "java"
apply plugin: "eclipse"
apply plugin: "idea"
apply plugin: "org.springframework.boot"
apply plugin: "io.spring.dependency-management"
apply plugin: "com.github.hierynomus.license"  // required license plugin

bootJar {
    baseName = "gs-spring-boot"
    version =  '0.1.0'
}

repositories {
    jcenter()
}

sourceCompatibility = 1.10
targetCompatibility = 1.10

dependencies {
    compile("org.springframework.boot:spring-boot-starter-web")
    testCompile("junit:junit")
}

Limited language and framework support

Having the need to build Gradle based Java 11 projects, I ran into 2 major issues:

  1. Developers were relying on Gradle in a specific version. GitLab's License Management image ships an older version of gradle within the image and it's impossible to match the developers required version. Gradle wrapper ./gradlew should be used instead.

    I recently contributed a SETUP_CMD environment variable to the core to bypass the package manager auto-detection and make use of the ./gradlew Gradle wrapper script.

  2. GitLab's License Management images support Java 8 only.

Using a custom licence management image

I've forked the GitLab.org / security-products / license-management project and started to work on the two issues listed above.

LanguageVersionFrameworkLicense scanner image
Java8Maven, GradleGitLab’s default image
10Gradle Wrapperregistry.gitlab.com/widerin/license-management:jdk10
11registry.gitlab.com/widerin/license-management:jdk11

The customized license_management job in detail

Below is an example of a Java 11 customized license_management job which uses my customized Docker image which is based on OpenJDK base images and supports gradle wrapper only, because it does not ship Gradle within the image.

# ...

license_management:
  stage: verify
  image:
    name: registry.gitlab.com/widerin/license-management:jdk11
    entrypoint: [""]
  variables:
    SETUP_CMD: ./gradlew --quiet --no-daemon assemble
  script:
    - /run.sh analyze .
  artifacts:
    reports:
      license_management: gl-license-management-report.json

# ...

Update

GitLab has upgraded their security products and license_management image now comes with Java 11 preinstalled - custom images are no longer required. See also the follow up post