check in build artifact and avoid endless build loop
I'm working on an RTC based project that uses Build Forge and trying
to come up with a good build reproducibility story. We already store ant scripts, makefiles, etc. in RTC of course, but Build Forge lacks a straightforward SCM mechanism for Build Forge projects. There is however a mechanism to export the project configuration to an XML file at build time -- this config file could in theory be imported into Build Forge at a later time and used to reproduce the build... So, my naive idea was to export the config just before the end of a successful build and check it in to RTC using scm command line. But, there's a catch-22 -- by checking something in during the build, we'll be creating a change that would be detected in the "build only if there are changes" next time the schedule runs so we create an endless build loop. Is there some way to have particular file(s) ignored in the check for changes? I feel like I must be missing something fundamental here but can't see how to ever check something in during a build and retain the value of build avoidance... |
2 answers
lmgray wrote:
There is As you discovered, that doesn't work well. A build should never check things into the same location where it gets the source that it builds. If the build has to check in something, it should check it in somewhere else. In this case you would want to check it into a separate SCM component in a separate stream. But a better solution would be to publish the XML file in the Jazz build result. As long as the Jazz build result is still in the repository, you can get at the Build Forge configuration necessary to reproduce the build. |
You can use the logPublisher Ant task to do what David suggests (see the Ant task reference in the Help).
Note, though, that you could use the SCM command line tool to add a new change set with a file (or files) to the build workspace, and deliver it to the stream, without causing another build, since the build workspace will be in sync with the stream. There are still issues with this approach, though, e.g. the file won't be in the snapshot created for the build. I think attaching the file to the build result makes more sense. |
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.