It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,788
×11,929
×562
×73

question asked: Jul 24 '14, 7:02 a.m.
question was seen: 5,930 times
last updated: Jul 29 '14, 11:07 a.m.

Related questions

FAQ - How this Forum works

RTC + Jenkins: Why is a new snapshot always created?

0
Rafael Rezende (43●17●23) | asked Jul 24 '14, 7:02 a.m.
I made some experiences using RTC and Jenkins to understand how and when snapshots are created. These were the scenarios:
  1. Conventional scenario of a Build Definition using a dedicated Build Repository Workspace;
  2. Using a Stream in the Build Definition instead of a Build Repository Workspace;
  3. Requesting a personal build from my personal Repository Workspace;
  4. Requesting a personal build from a Stream.
I noticed that only in the first case a new snapshot was created. Also, I believe that there are no Accept at all in the other use cases. Therefore, I'm assuming that snapshots are created only when an Accept is performed. Is this right?

Supposing I have a snapshot on a Stream, and several changeset on top of it. If I request a build from that Stream, no snapshot is created, but what is getting actually built in this scenario?

Finally, in the item 1 above, a new snapshot is created even if there are no changesets to be accepted. Is there any other reason to create snapshots in this case?

Accepted answer

1
permanent link
Nick Edgar (6.5k●7●11) | answered Jul 24 '14, 11:48 a.m.
JAZZ DEVELOPER
Hi Rafael,
> Therefore, I'm assuming that snapshots are created only when an Accept is performed. Is this right? 
Yes.

> Supposing I have a snapshot on a Stream, and several changeset on top of it.
It will build the latest in the stream, ignoring any past snapshots. Note that if you're building directly against the stream, there's no isolation from ongoing deliveries to the stream while the build is running, so what gets loaded may not be consistent.

>  a new snapshot is created even if there are no changesets to be accepted. Is there any other reason to create snapshots in this case?
Not particularly, but this way each build gets its own snapshot, so if others get deleted there's no downstream impact. The snapshot also gets a label that's consistent with the build's.  This could be optimized out, but snapshots are actually pretty lightweight (it will point to previously created baselines).  An extra compare between last snapshot and latest build workspace state would be needed too.
Rafael Rezende selected this answer as the correct answer
Comments
Rafael Rezende commented Jul 28 '14, 5:42 a.m.

Hi Nick,

Thanks for your answer!
If I understood then, the relation between Build Result and Snapshots is always 1:[0..1], right?

We actually have a requirement in which we should achieve a N:1 relation, that is, if we build a project using an old snapshot, the Build Result should have a link to that old snapshot, which could, on the other hand, be referenced by several Build Results.
The purpose of this requirement is, first, to keep the traceability between Build Results; to know which ones were built using the same Snapshot.
Secondly, we have several product lines in which the same source is used, but every product uses a different configuration. So, the snapshot is "the common reference" between every Build Result.

I've tried several ways to link an existing Snapshot to a Build Result. But either the BR ended up linked to a new snapshot, or linked to no snapshot at all. I assume this requirement is not possible to achieve then...

Nick Edgar commented Jul 28 '14, 12:03 p.m.
JAZZ DEVELOPER

Interesting scenario. Since 5.0, we have the snapshotPublisher Ant task that allows the snapshot contribution for the build to be updated. This was added to support the use case where the build itself delivers changes back to the stream, and you want to include those in the (new) snapshot for the build.


Although we don't currently support building directly against a snapshot (see Allow building against existing snapshot (90272)), this can be scripted using the SCM CLI to populate the build workspace from a referenced snapshot.  So it should be possible to model your arrangement.

Rafael Rezende commented Jul 29 '14, 9:32 a.m.

If I create a new Repository Workspace from a Snapshot via RTC client, and run a personal build against it, the resulting Build Result will not have a link to the Snapshot that generated the Repository Workspace first place.
Is it the same behavior of using the SCM CLI?

(note: in our company we are still using the 4.0.6 until the end of the year.)

1
Nick Edgar commented Jul 29 '14, 11:07 a.m.
JAZZ DEVELOPER

Yes, that's correct. It's also possible to do some of these things using scripting, e.g. see https://jazz.net/wiki/bin/view/Main/GroovyScripting

This has the advantage of working against earlier versions of RTC, as long as you limit yourself to the APIs available then.
If you'd like to explore this, i.e. replacing the snapshot contribution, I'd be happy to help.

Your answer

Register or to post 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.