team_scm_snapshotUUID Environment Variable Overwritten when Loading Jenkins Pipeline Library

Kirk Vogen (127●14●18) | asked Mar 09 '17, 11:20 a.m.
edited Mar 14 '17, 10:11 a.m.

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_snapshotUUID should 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 @Library annotation. 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, the team_scm_snapshotUUID environment 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_snapshotUUID environment variable. Since the team_scm_snapshotUUID environment variable is now set to the pipeline library's snapshot UUID, the source code for the project being built is not loaded.

We have worked around the issue by using the


            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)}
}

This workaround resolves the issue. It would be nice to not need the workaround. That way, the compile-time checks that come with


        @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

Most liked answers|Newest answers|Oldest answers ↑

permanent link

Rob Leach (35●4●8) | answered Aug 20 '17, 1:34 a.m.

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.

The reason why I believe that's a possibility is because I've modified my Global Shared Library configuration in the Manage Jenkins -> Configure System page to override the default snapshot name, and that snapshot override is what the build picks up as the snapshot UUID's name.

When I do a scm checkout later in my Jenkins Pipeline script, as an example from a product Stream, I can set the snapshot name (override the default), and after the build I can verify that the Stream does have a new snapshot with the snapshot name I provided. But the issue is I can't publish a meaningful snapshot to the RTC build result because the snapshot UUID I have in the team_scm_snapshotUUID property is the snapshot UUID for the library fetch, and not the Stream fetch.

So my guess is that property is being set on the initial library fetch, and can't be modified again for the life of the build.

I'd hoped that I could somehow override the behavior, or have a list of snapshot UUID's that I could choose from, or at the time of the fetch from the Stream I care about, claim the snapshot UUID for that fetch and use it to publish my snapshot to the RTC build result. As it is now, when I do publish a snapshot to the RTC build result using team_scm_snapshotUUID, I get the snapshot of the Global Shared Library repository workspace which is clearly not what I want or need (it's meaningless to developers to see that snapshot when they really care about the snapshot for the product Stream they work in).

IBM, do you have any direction on how to resolve this issue, or implement a correct solution to publish a meaningful snapshot back to the RTC build result in the described scenarios? I'm hoping I've just implemented my solution incorrectly, and there is a way to get the snapshot UUID of a specific scm fetch, and not just the very first one that occurs during the build.

Kirk, thanks for outlining your work around. I'll have to look into it, but it's likely we wouldn't accept it due to losing the benefits of the @Library method of library loading.

Comments

Rob Leach commented Aug 20 '17, 2:10 a.m.

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.

I guess I'll have to experiment further to get any conclusive result either way....

Rob Leach commented Aug 21 '17, 10:11 p.m.

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.

permanent link

Lakshmi Narasimhan T V (441●5) | answered Dec 07 '17, 11:35 a.m.
JAZZ DEVELOPER

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

Kirk Vogen commented Dec 15 '17, 10:54 a.m.

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.

We've since worked around the issue by using the RTC web API. Instead of using the team_scm_snapshotUUID property, we hit the web API passing the build result UUID. This call gives us the build details back. We parse through those build details using some Ruby and are able to get the snapshot UUID. It is somewhat involved, but works.

The workaround that you pointed out seems a lot simpler, though! I'll give it a try when I have an opportunity to do so.

It's all about the answers!

Related questions

team_scm_snapshotUUID Environment Variable Overwritten when Loading Jenkins Pipeline Library

2 answers

Your answer