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...
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:
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.
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.
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.
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.