team_scm_snapshotUUID Environment Variable Overwritten when Loading Jenkins Pipeline Library
We are running into an issue where the build's
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
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
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. |
Hi Kirk,
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.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.