team_scm_snapshotUUID Environment Variable Overwritten when Loading Jenkins Pipeline Library
We are running into an issue where the build's
team_scm_snapshotUUID
environment variable is lost when using a pipeline shared library where the shared library is stored in RTC's SCM. Here is our configuration:
-
The build in Jenkins uses a pipeline script. That script is loaded from the SCM using the Pipeline script from SCM option in the build's configuration. In the dialog, we enter the build definition name and the path to the pipeline script. When the build runs, at this point the correct
team_scm_snapshotUUIDshould presumable be stored as an environment variable (but not accessible since this occurs outside of the pipeline script). -
Jenkins parses our pipeline script and notices that it has an
@Libraryannotation. As such, it loads the pipeline library from RTC. It knows to load the library from RTC since it is configured to reside in RTC via Manage Jenkins > Configure System > Global Pipeline Libraries. Pipeline libraries are loaded by providing a version. In the case of RTC, the version corresponds to a snapshot name (e.g.1.0). After the load, theteam_scm_snapshotUUIDenvironment variable is now set to the UUID of the library snapshot name. Now we have a problem. -
The first stage in our pipeline loads the source from RTC within a node. It uses the teamconcert step passing it the
team_scm_snapshotUUIDenvironment variable. Since theteam_scm_snapshotUUIDenvironment variable is now set to the pipeline library's snapshot UUID, the source code for the project being built is not loaded.
library
pipeline step (which is evaluated at runtime) instead of the
@Library
annotation which is evaluated at compile time. Our workaround in our pipeline script is as follows:
// Store the build's snapshot UUID before loading the library
snapshotUUID = env.team_scm_snapshotUUID
library "my-library@1.0"
stage("compile") {
// Call a function in the shared library
somethingNecessaryToDoBeforeRetrievingSource()
// Get the source from RTC
teamconcert buildType: [
value: "buildSnapshot",
snapshotOwnerType: "workspace",
buildSnapshot: snapshotUUID,
createFoldersForComponents: true]
// Rest of build steps (e.g. compile source code)}
}
@Library
could be utilized. Any thoughts as to whether this issue would be feasible to fix in the Jenkins Team Concert Plugin implementation?
2 answers
We have the same problem. But I think the issue is that the team_scm_snapshotUUID property (or environment variable) is immutable. My speculation is that once that property is initially set, it can't be changed thereafter. So the first thing that is being retrieved from RTC when you have a Jenkins Pipeline script that is using Global Shared Library (as you outlined) is your library, and that sets the team_scm_snapshotUUID to the snapshot UUID for that scm fetch, and then that persists throughout the build process.
Comments
I have another data point to add. In reviewing a Jenkins build job status page, I noticed that the snapshot and stream information is listed. Now I'm starting to wonder if the snapshotUUID (or team_scm_snapshotUUID property) correlates to those streams that have change sets associated with them for the build in question.
Even with multiple change sets across multiple components, only the first snapshot from the Global Shared Library scm fetch is part of team_scm_snapshotUUID.
Hi Kirk,
Could you try the workaround mentioned here https://wiki.jenkins.io/display/JENKINS/Team+Concert+Plugin#TeamConcertPlugin-Workaround ? Since you checkout code using Pipeline from SCM, the position of RTCBuildResultAction in the list should be fixed.
Fix for Jenkins issue allows the checkout step to return a map. Team Concert Plugin requires an adoption (see work item 446242). Once that is done, checkout step will return the environment variables from RTCScm as a map.
Comments
Thanks. I read through the wiki post and I think that would solve the problem. Next time we have an opportunity to update our build code, I will give it a try.