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 notelicense_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:
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
./gradlewshould be used instead.I recently contributed a
SETUP_CMDenvironment variable to the core to bypass the package manager auto-detection and make use of the./gradlewGradle wrapper script.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.
| Language | Version | Framework | License scanner image |
|---|---|---|---|
| Java | 8 | Maven, Gradle | GitLab’s default image |
| 10 | Gradle Wrapper | registry.gitlab.com/widerin/license-management:jdk10 | |
| 11 | registry.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 andlicense_management image now
comes with Java 11 preinstalled - custom images are no longer required. See
also the follow up post