Is it possible to build a snapshot alone? not rebuild an existing build
2 answers
Unfortunately creating a workspace from the snapshot & then using a personal build is the only way I know how to accomplish what you are trying to do. I completely understand & agree that this is unpalatable. I've raised this very issue in the past with RTC development; I think there was an RFE opened to address it, but offhand I can't remember the number.
Comments
Yes, that's correct. We have this enhancement request: Allow building against existing snapshot (90272)
See also related items of #90272 if that's not an exact match.
Sometimes you don't have the original build & you need to be able to reliably recreate a historical build. In my previous job we had finite storage capacity for keeping builds around...it didn't happen often but occasionally we would be asked by SVT to recreate a build from the recent past whose daily build retention period had expired.
Also, some products/solutions must be able to show that they could reliably recreate a historical build (even if in practice they would never have to do it) because of audit requirements.
So the problem is just that the resulting build is a personal build rather than a regular one? Or are there deeper issues? I can imagine some, e.g. build not reproduceable for other reasons (e.g. build definition changed, tool chain on build machine changed, etc)?
Absolutely: there's a lot that goes in to making builds reproducible. My general impression was that reproducibility wasn't a design concern for RTC. You can make it work, sort of, but it's not something RTC supports in a first class way.
Re. personal builds, two complaints off the top of my head:
- It renders the personalBuild flag useless. If every production rebuild is going to be a personal build then I can't use the personalBuild flag in my script to do things differently in a personal build. The typical workaround for this that I've seen in the wild is to have a different build definition that is used exclusively for personal builds, but that kind of defeats the purpose IMO.
-
It's error prone. The more steps involved the more chance for human error. Keep in mind that in some (many?) organizations, the folks requesting builds are not developers but rather release or project managers.
@Nedgar The reason why personal build work work: (We have only one stream)
Also we need this build to be an official one (meaning reproducible) & attach Release to the build
Just to add my opinion, the approach of creating a workspace from the snapshot then using a personal build on it has a serious flaw:
In my understanding, Streams and RWS are meant to be volatile; easy to create and delete, which even justifies this approach just to achieve a rebuild.
On the other hand, the resulting Build Result does not carry the stamp of the snapshot it has built. Instead, it contains a reference to the RWS, which is lost as soon as the RWS gets deleted (unless you want to keep a RWS for every rebuild forever...).
So, what we have after all is the original Build Result, pointing to the actual snapshot and RWS; and a rebuild Build Result, orphan, with no references at all...