creating snapshots from Build Forge
We have been using the RTC/BF integration for some time, and for the most part it does a good job. The one issue I haven't been able to solve is around snapshots.
With the ant_rtc_helper.xml we started using in rtc 2.x a snapshot is created for every build, this includes CI builds where no changes were found, so in fact no build was executed. The snapshot we create is linked to the BF TAG, so we have snapshots that look exactly the same, which is a problem. I know in rtc 3.0 we can create a snapshot, and promote it from the command line, but in order to promote a snapshot we need them to be unique. Leveraging the "scm create snapshot" command won't really work because the snapshot won't get added to the build summary. So my question, how do we modify the current xml file seperate the accept, from the snapshot creation? Does the new rtc/bf integration do this for us, i.e use the jbe for the accept? |
6 answers
|
I think i can strip the snapshot parm from the initial accept target, and then add another step to my project which calls a new target, "snapshot". Snapshot will simply call the accept class in the original xml, but this time have the snapshot param. For example:
<target> <tstamp> <format> </tstamp> <teamAccept> <workItemPublisher> <delete> </target> <target> <teamAccept> I am not sure what the affects will be calling the accept class twice within a single build, or if the second accept will cause a failure. The other issue that could occur is that more changes were delievered to the stream, and changes from the second accept will be included in the build, but fail to show in the build overview. |
Hi Daniel,
I can't see your script above because the forum software munged it. Be sure to check "Disable HTML in this post" when posting a note that has XML/HTML tags. Also note that that setting gets lost when you use Preview (sigh). Are you using the SCM CLI to create the snapshot currently, or letting the teamAccept Ant task do it? Since 2.0.0.1, it's possible to get the snapshot UUID out of the teamAccept task using <teamAccept ... snapshotUUIDProperty="snapshotUUID"/>. That is, it takes the name of a property to set with the snapshot UUID. You could then pass this to the SCM CLI invocation to identify the snapshot to promote. As of 3.0, it's also possible to use invoke JBE to do the SCM phase of the build (the accept/fetch), and that's now the recommended way to do so from a BF build. It will only create the snapshot if needed, but unfortunately there's no easy way to get back the snapshot UUID. See "Using Jazz Source Control in a Build Forge project using the JazzJBE.xml adapter" in Peter Birk's article at: https://jazz.net/library/article/607 The JazzJBE.xml adapter ships with BF 7.1.2, or can be found here if needed: https://jazz.net/wiki/bin/view/Main/RationalBuildForge/RTC3M6BFIntegrationEnhancements You might also want to scan the other topics at: https://jazz.net/wiki/bin/view/Main/RationalBuildForge These were written while 3.0 was under development, and were the source material for the article. |
|
Hello Nick,
Thanks for the information. We have been planning to leverage the new JBE capabilities, but given the large number of build definitions, around 200, the migration is a bit tricky. Not only do we have to enable the Jazz source control in the build configuration, modify all the corresponding BF projects, but we have to modify the build files maintained in RTC. That is a topic we can saver for another thread. What I am wondering is if we can leverage the new adapter without changing the build configuration? My gut tells me no, because the new adaptor does an accept/fetch in a single action. In order to fetch the WS the JBE needs that information. The JBE will retreive that information from the "Load Options". |
|
That's correct, in order for JBE to run the SCM phase, it needs the configuration info in the Jazz Source Control page of the build definition, such as the build workspace and load directory.
|
|
Thanks for the help, I will look into how we can migrate to the leverage the JBE in the best way possible.We create a new sandbox for every build, allowing teams to run builds in ||, so our load directory has to be unigue. We can use the buildresultUUID to create a new sandbox for every build. I have to find a way to use that variable through out our heirachy of env. I would have expected the buildresultuuid to be populated when rtc initiates the build in BF. That might be the case, but BF doesn't have a value for it until it gets down to the project specific env, instead of an env higher up, say at the server level.
I will update the forum on how we solve the problem, hopefully withot having to update 200 BF env. |
|
Yes, the buildResultUUID can be used as a variable in the load directory field in the build definition, e.g. /some/path/${buildResultUUID}.
The buildResultUUID var is set in the BF environment when the BF job is kicked off, but only in the job's project environment. |
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.