Continuous Integration: Releases Maven
Contents
Maven Build Profiles
A gCube artifact can be built in 3 different situations:
- on a personal (development) machine, likely after new code has been developed, by a gCube developer
- on a Jenkins slave, likely triggered by a new commit in the Git repository
- on a Jenkins slave, as part of the release pipeline
To support these scenarios, the following profiles are defined in the gCube maven-parent.
gcube-developer
- Dependencies resolved against gcube-snapshots and gcube-releases
- Snapshot artifacts deployed to gcube-snapshots
- Deployments of releases artifacts are not permitted
jenkins-snapshots
- Dependencies resolved against local-snapshots and gcube-releases
- Snapshot artifacts installed to local-snapshots
- Snapshot artifacts deployed to gcube-snapshots
- Deployments of release artifacts are not permitted
jenkins-releases
- Dependencies resolved against gcube-releases
- Deployments of snapshot artifacts are not permitted
- Release artifacts deployed to gcube-releases
dry-run
This profile disables all the deployments (regardless the maven commands) by skipping the deploy phase. It can be combined with the previous profiles
disable-java8-doclint
This profile sets an additional parameter for javadoc generation to disables the doclint. It avoids the build fails if formal/syntax errors are found in javadoc comments.
Maven Settings Files
The activation and switch among the build profiles is done through different settings.xml files available in the Configs project.
gcube-developer-settings.xml
Used by: gCube Developer Installed on: development machine
jenkins-snapshots-settings.xml
Used by: Jenkins jobs Installed on: slave node
jenkins-snapshots-dry-run-settings.xml
Used by: Jenkins pipeline jobs When: To test a complete snapshot without deploying on a remote repo Installed on: slave node
jenkins-release-settings.xml
Used by: Jenkins pipeline jobs Installed on: slave node
jenkins-release-dry-run-settings.xml
Used by: Jenkins pipeline jobs When: To test a complete release without deploying on a remote repo Installed on: slave node
Build Configurations
The build configurations must guarantee the integrity of the Continuous Integration pipeline. Jenkins builds must use only the outcomes of other Jenkins builds. A snapshot artifact built on a development machine and deployed to Maven snapshot repository is a potential threat for the integration process. There are several cases in which such an artifact could be not in sync with the content of the SCM repository. For instance:
- it is built from a branch not built on Jenkins,
- the source code that generates it is committed but not pushed
- it has dependencies on the local environment not reproducible on the Jenkins slaves
- ..and so on
What we need
- Jenkins must use only artifacts generated by Jenkins builds to resolve dependencies.
- Snapshot artifacts deployed to Maven snapshot repository by developers must not be seen by Jenkins
- Jenkins must deploy to Maven snapshot repository after successful builds
- Release artifacts are built and deployed to the Maven release repository (gcube-releases) only by Jenkins
What we are trying to avoid
- Reconfigure all the Jenkins projects at each release time
- Change all the poms before starting the release integration
- Create ad-hoc artifacts or repositories
By combining the build profiles in the appropriate settings file, we support the following build configurations with the Maven Repositories:
Why not the Maven Release Plugin
gCube does not use the Maven Release plugin to release its artifacts. The simple explanation is that the plugin does not make any use to gCube. The plugin is designed for *SINGLE* artifact releases, not for multi-project releases like gCube. It also assumes that a human intervention during the release process (for instance, it prompts for the tagname) for each component, obviously not feasible in a gCube release.
At the time we are setting up this release process, it would be an over-complication to configure each Jenkins project with an invocation to the plugin and parametrize each build process to activate the plugin during the release build. This can be eventually be investigated in the future.
Back to the CI guide.