Is it possible to build a snapshot alone? not rebuild an existing build

Karthik Krishnan (878●5●111●158) | asked Mar 06 '14, 9:41 a.m.
edited Mar 06 '14, 9:42 a.m.

We have builds and Streams. Build works on a workspace which points to latest on stream.

My question: A Stream has many snapshots and is it somehow possible to select one snapshot and request a build?

All I can think of is to use SCM tools for this. Are there any other alternatives?

I don't want to create a workspace out of this snapshot and pass that to a build (personal build) as I need the final build snapshot as this output would be sent to customer.

2 answers

Most liked answers ↑|Newest answers|Oldest answers

permanent link

Jeff Care (1.0k●37●33) | answered Mar 06 '14, 9:46 a.m.

I was about to answer, but then I saw your edit about what you don't want to do...

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

Nick Edgar commented Mar 06 '14, 9:51 a.m.

JAZZ DEVELOPER

Yes, that's correct. We have this enhancement request: Allow building against existing snapshot (90272)

But it's not clear to me why doing a workspace copy / personal build from a previously built snapshot doesn't work for you. In fact, if you still have the original build, why do you need to run it again?

Knowing some more details about your scenario would help in recommending alternatives.

Nick Edgar commented Mar 06 '14, 9:51 a.m.

JAZZ DEVELOPER

See also related items of #90272 if that's not an exact match.

Jeff Care commented Mar 06 '14, 10:12 a.m. | edited Mar 06 '14, 10:15 a.m.

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.

Nick Edgar commented Mar 06 '14, 10:27 a.m.

JAZZ DEVELOPER

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)?

Jeff Care commented Mar 06 '14, 10:52 a.m.

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.

Karthik Krishnan commented Mar 06 '14, 10:57 a.m.

@Nedgar The reason why personal build work work: (We have only one stream)

- Time T0, team freezes code & build happens & a RWS has been created on the build snapshot (Say Monday)

- Time T1, System testing happens (say Tuesday)

- Time T2, Team continues delivery of code for next release (Say Tue,Wed)

- Time T2, System testers find bug

- Time T3, developer fixes bug and delivers to stream

At this point, we cannot take the latest on stream and do a build as this has code for future release. What we do is take this bug fix change set to already created WS. Create a snapshot and promote this to stream

Now the team wants to build on this snapshot. This whole scenario can be different when we have streams for Dev, Integration etc

Karthik Krishnan commented Mar 06 '14, 10:59 a.m.

Also we need this build to be an official one (meaning reproducible) & attach Release to the build

Rafael Rezende commented Jul 29 '14, 12:03 p.m.

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

showing 5 of 8 show 3 more comments

permanent link

Madhu Prabhu (98●11●14) | answered Jul 30 '14, 10:12 a.m.

You can create a build based on a snapshot without having to create a new workspace. Open the build repository workspace and under Components - remove exisiting components, select Add and the option 'Components from a snapshot' and you can pick all components of the snapshot you want from the relevant stream. Remove any flowtargets you have set up for that workspace so there is no possibility of inadvertantly getting latest from the stream it is flowing to or from. Run the build.......

It's all about the answers!

Related questions

Is it possible to build a snapshot alone? not rebuild an existing build

2 answers

Your answer