Difference between revisions of "Continuous Integration: Releases Maven"
Manuele.simi (Talk | contribs) (→Why not the Maven Release Plugin) |
Manuele.simi (Talk | contribs) (→Maven Build Profiles) |
||
(7 intermediate revisions by 4 users not shown) | |||
Line 5: | Line 5: | ||
# on a Jenkins slave, as part of the release pipeline | # on a Jenkins slave, as part of the release pipeline | ||
− | To support these scenarios, the following [https://maven.apache.org/guides/introduction/introduction-to-profiles.html | + | To support these scenarios, the following [https://maven.apache.org/guides/introduction/introduction-to-profiles.html build profiles] are defined in the gCube [[Maven_Configuration#Maven_Parent|maven-parent]]. |
== gcube-developer == | == gcube-developer == | ||
− | * Dependencies resolved against gcube-snapshots and gcube-releases | + | * Dependencies resolved against local, gcube-snapshots and gcube-releases |
+ | * Snapshot artifacts installed to local | ||
* Snapshot artifacts deployed to gcube-snapshots | * Snapshot artifacts deployed to gcube-snapshots | ||
* Deployments of releases artifacts are not permitted | * Deployments of releases artifacts are not permitted | ||
Line 17: | Line 18: | ||
* Snapshot artifacts deployed to gcube-snapshots | * Snapshot artifacts deployed to gcube-snapshots | ||
* Deployments of release artifacts are not permitted | * Deployments of release artifacts are not permitted | ||
+ | |||
+ | == jenkins-staging == | ||
+ | * Dependencies resolved against local-staging and gcube-jenkins-staging | ||
+ | * Release/snapshot artifacts installed to local-staging | ||
+ | * Release/snapshot artifacts deployed to gcube-jenkins-staging | ||
== jenkins-releases== | == jenkins-releases== | ||
− | * Dependencies resolved against gcube-releases | + | * Dependencies resolved against local-releases and gcube-releases |
+ | * Release artifacts installed to local-releases | ||
* Deployments of snapshot artifacts are not permitted | * Deployments of snapshot artifacts are not permitted | ||
* Release artifacts deployed to gcube-releases | * Release artifacts deployed to gcube-releases | ||
Line 79: | Line 86: | ||
By combining the build profiles in the appropriate settings file, we support the following build configurations with the Maven Repositories: | By combining the build profiles in the appropriate settings file, we support the following build configurations with the Maven Repositories: | ||
+ | |||
[[File:CI_Maven_Repos.png|800px]] | [[File:CI_Maven_Repos.png|800px]] | ||
Line 84: | Line 92: | ||
gCube does not use the [https://maven.apache.org/maven-release/maven-release-plugin| 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. | gCube does not use the [https://maven.apache.org/maven-release/maven-release-plugin| 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 | + | Moreover, Maven Release plugin was created years before people started realizing that software production has to become smoother and continuous. Main problems with the plugin include: |
+ | |||
+ | * It is not atomic. If release goal fails for some reason, POMs are committed and possibly broken. | ||
+ | * It spoils the commit history, making it unreadable if you want to have frequent releases. | ||
+ | * It tries to own multiple responsibilities (managing versions, committing stuff, creating tags etc). | ||
+ | |||
+ | 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 investigated in the future. | ||
''Back to the [[Continuous_Integration_procedure_(2019) | CI guide]].'' | ''Back to the [[Continuous_Integration_procedure_(2019) | CI guide]].'' | ||
+ | |||
+ | [[Category:Continuous_Integration]] |
Latest revision as of 05:01, 12 September 2019
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 build profiles are defined in the gCube maven-parent.
gcube-developer
- Dependencies resolved against local, gcube-snapshots and gcube-releases
- Snapshot artifacts installed to local
- 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-staging
- Dependencies resolved against local-staging and gcube-jenkins-staging
- Release/snapshot artifacts installed to local-staging
- Release/snapshot artifacts deployed to gcube-jenkins-staging
jenkins-releases
- Dependencies resolved against local-releases and gcube-releases
- Release artifacts installed to local-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.
Moreover, Maven Release plugin was created years before people started realizing that software production has to become smoother and continuous. Main problems with the plugin include:
- It is not atomic. If release goal fails for some reason, POMs are committed and possibly broken.
- It spoils the commit history, making it unreadable if you want to have frequent releases.
- It tries to own multiple responsibilities (managing versions, committing stuff, creating tags etc).
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 investigated in the future.
Back to the CI guide.