Continuous Integration: Tagging Jenkins Pipeline
gCubeTagging Pipeline Project
In gCube we use a Pipeline to tag all the repositories forming a gCube Release. The pipeline project is available at: https://jenkins.d4science.org/job/gCube-Tagging/
The pipeline takes as input the parameters needed to locate a commits report.
The commits report is generated by the Release pipeline. The tagging pipeline assumes that the report is available at:
No triggers are defined because the pipeline is expected to be manually launched by the Release Manager:
It can be changed according to the release needs and the availability of a sufficient number of dedicate agents in Jenkins.
The pipeline is maintained in a Git repository. This section connects the project to the Git repository.
Jenkins Pipeline Definition
The definition of the gCube release pipeline is maintained in this Git Repository: https://code-repo.d4science.org/gCubeCI/gCubeTagging.
Requirements on Jenkins
- Jenkins ver. 2.164.2 or newer
- Pipeline Plugin
- Pipeline: Basic Steps
- Pipeline: Maven
- Pipeline: SCM Step plugin ver. 2.7 or newer
- Pipeline: Shared Groovy Libraries ver. 2.15 or newer
- User credentials configured on Jenkins. These are needed to set the author of the tag. git.gcube is currently used
Jenkins Pipeline Execution
In order to use as input the following sample report available at https://code-repo.d4science.org/gCubeCI/gCubeRelease/raw/branch/master/releases/4.10.0/build_commits.12.csv:
GroupID,ArtifactID,Version,SCM URL,Build Number,Distribution URL,Filename,Packaging org.gcube.tools,strategy-forward,1.1.0,https://code-repo.d4science.org/Playground/MergeStrategyFastForward,66f5fd1da37229615268955eeaf46870dd4d6576,...
We run the pipeline with the following parameters:
- Type = TAG
- gcube_release_number = 4.10.0
- report_number = 12
On the jenkins console, we can see the messages logging the tagging activity on the repository:
On gitea, we can appreciate that the tag has been pushed;
On a local cloned repo, we can fetch the new tag:
The pipeline must tag the master branch at the commit ID reported in the build report.
The commit is tagged twice:
- v<component version>
- r<Gcube Release number>
If the pipeline execution succeeds, it sends a tag report to the release manager. The report includes the following information for each Git repository tagged:
- the artifact id
- the artifact version
- the SCM url
- the commit tagged
- the component tag pushed to the repository
- the gCube release tag pushed to the repository
Here's an example of a tag report:
The tagging pipeline will be soon also in charge of creating the release notes. This is the expected action plan:
- the developer must add a related section to CHANGELOG.md *before* each release. The section must be compliant with the template
- upon the reception of the release ticket, the release manager checks and validates the changelog section for the component
- the release pipeline may enforce the presence of the changelog.md and of a section related to the current version of the artifact (i.e. it fails if both conditions are not matched)
- the tagging pipeline may create an aggregated changelog, with all the sections from the single changelogs...and send it to "Someone" in charge of creating the release notes.
- "Someone" elaborates the changelogs, merges them and produces a narrative for each major feature across all the released component.
Back to the CI guide.