Continuous Integration: Releases Maven

Maven Build Profiles

A gCube artifact can be built in 3 different situations:

1. on a personal (development) machine, likely after new code has been developed, by a gCube developer
2. on a Jenkins slave, likely triggered by a new commit in the Git repository
3. 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.