It's all about the answers!

Ask a question

Is it possible to have two almost identical build definitions for a single work space repository?


Claus Jensen (3112) | asked Sep 06 '12, 8:59 a.m.
Hi,

I have a build definition which polls every 10 minutes for changes and starts only a new build if any changes are accepted. 

 Can I create a build definition to invoke a single build during night time, without any new changes has been accepted? The two definitions will be almost identical except from the scheduling and condition for starting a new build. 

 I have tried a couple of designs, but I always mess up the version numbers for the builds.

 I am using the Jazz Build enginge as build engine. And Visual build pro 7.7 to define the actions during the build. I have tried to use the same worksspace repository and sandbox with no luck. 

 Has anyone in this forum any successful experiences? 

 Thanks in advance. 
 Best regards Claus Jensen

Accepted answer


permanent link
Nick Edgar (6.5k711) | answered Sep 06 '12, 10:30 a.m.
JAZZ DEVELOPER
 Hi Claus,

Since the "Build only if there are changes accepted" flag applies to the whole definition, not individual schedule entries, you'll need two build definitions, one for the 10 minute interval (with that flag checked) and one for the nightly build (with that flag unchecked).  I assume you tried this approach, but I'm not clear on what you mean by "I always mess up the version numbers for the builds".  

Also, keep in mind that if 2 build definitions use the same build workspace, there may be race conditions between them for the accept/fetch, so in general we recommend that each build definition have a unique build workspace.  The build definition editor should warn if that's not the case.

Another option would be to have the 2nd build definition trigger the 1st, using the requestTeamBuild Ant task (check the Help).  In this case the build definition would not need to be configured for Jazz SCM itself, since all it does is trigger the 1st build.
Claus Jensen selected this answer as the correct answer

Comments
Claus Jensen commented Sep 07 '12, 9:28 a.m.

Hi Nick,

It's a good idea to let the 2nd definition trigger the 1st definition.

When reading about the requestTeamBuild, I understood the task is running on every other engines except from JBE that I am using. Is it correct? So I would have to create a second engine to trigger the 1st definition?

As you correctly assumed I have tried with two build definitions sharing the same build workspace. I get the recommendation to avoid shared build workspaces.

As for the version numbers for the builds, I think I have some problems in keeping the version numbers up to date, when I try with two definitions with their own build workspace and sandboxes. I as understand Jazz source control, every time I deliver the file storing the version numbers from the continuous build, the file should be available in the stream it was delivered to. And when the second definition at nighttime tells to accept the changes into its own build workspace and sandbox, the updated version number file, is accepted and I can use the updated file in the build.

Is that right?

Thanks for your first answer

Best regards Claus


Nick Edgar commented Sep 07 '12, 9:57 a.m.
JAZZ DEVELOPER

If the first build blocks waiting for the requested build to complete, using the waitForTeamBuild Ant task, then, yes, you would need to run a 2nd JBE. But requestTeamBuild just puts the request in the queue, it doesn't wait for it to complete. So if that's all the script does, it will exit after issuing the request, freeing up the JBE to do the requested (or some other) build.

Regarding version numbers, I'm not sure what you mean by the version number file. This is not a concept from Jazz SCM, so I assume it's something specific to your build. But, in general, the SCM phase of a build does an accept into the build workspace from its target stream(s) then loads that workspace. Whether sharing the build workspace with another build definition or not, it should get the latest from the target stream(s).


Nick Edgar commented Sep 07 '12, 9:57 a.m.
JAZZ DEVELOPER

The risk with having multiple definitions share the same build workspace is that there could be race conditions between the accepts and fetches of one build and another. JBE is smart enough to detect that and fail the build, rather than loading some mix of two accepts and continuing blindly. It also confuses the change history, e.g. the list of work items associated with builds for build def A may appear to be missing some, if their changes got accepted into a build for build def B. Work items are associated with a build when their associated change sets are accepted into the build workspace, which normally would happen at most once.


Claus Jensen commented Sep 11 '12, 4:16 a.m.

Thank you for your answer Nick.

2 other answers



permanent link
Cristian Gheorghe (122) | answered Aug 28 '13, 2:32 p.m.
It also confuses the change history, e.g. the list of work items associated with builds for build def A may appear to be missing some, if their changes got accepted into a build for build def B. 

Regarding the same scenario as above (separate build definition for nightly vs on-demand builds), using the same workspace, I can see how neither build will have a complete list of work items, however I was wondering if there would be any issue tracing changes when diffing snapshot baselines. I don't think there would be since snapshots created by these different build definitions would still be created in the same workspace, but just checking.

build-A_yymmdd-hhmm-1
build-A_yymmdd-hhmm-2
build-B-yymmdd-hhmm-1
build-A-yymmdd-hhmm-3

If I get the diffs between snapshot build-A_yymmdd-hhmm-1 and build-A-yymmdd-hhmm-3 I hope it does include work items in snapshot build-B-yymmdd-hhmm-1.


permanent link
Nick Edgar (6.5k711) | answered Aug 28 '13, 5:46 p.m.
JAZZ DEVELOPER
Cristian, the snapshot is created after accepting changes into the build workspace.  It's a complete picture of the state of the workspace after the accept, not just a recording of which changes were accepted, whereas the "included in build" work item links represent just the delta, i.e. those work items that were associated with the newly accepted changes.

As such, the snapshot history of the workspace will be consistent.  However, if you're looking at the history of builds for def A and comparing their snapshots, they may well contain changes that were actually accepted by builds for def B.


Comments
Cristian Gheorghe commented Aug 28 '13, 6:33 p.m. | edited Aug 28 '13, 7:28 p.m.

 Thanks Nick, that's what I thought. Whether or not I use a separate build def for the nightly, in  the end, remains to be seen, but good to know that at the very least, I can compare snapshots and be able to look at diffs/changes as they traverse the two builds, which is what I am concerned with, mostly.


I get some heat that people can't distinguish the nightly build (mainly I suppose when the email goes out) from the intra-day builds b/c the only thing they can go on to figure it's a nightly is the timestamp (scheduled build). Any idea as to how I can have a scheduled build somehow change the snapshot baseline name, or, the email title (or a part of it) changed to something that stands out ..ie NIGHTLY_*  which would alert developers that it's a build they better pay attention to? 

I know, it does not make a lot of sense but this is the requirement :-)


Nick Edgar commented Aug 28 '13, 7:32 p.m. | edited Aug 28 '13, 7:34 p.m.
JAZZ DEVELOPER

The simplest way to distinguish builds is to set a buildLabelPrefix property in the definitions, with value "N" for nightly builds and value "C" for continuous builds, so instead of just the timestamp like "20130828-1933" the build label will be "N20130828-1933" or "C20130828-1933".

You could also use the SCM CLI to change the label of the snapshot, e.g. using scm snapshot propertyset <connection options> name NEW_NAME ${team.scm.snapshotUUID}
We want to make this kind of thing easier.  See:


Cristian Gheorghe commented Aug 29 '13, 5:02 p.m. | edited Aug 30 '13, 9:47 a.m.

 > The simplest way to distinguish builds is to set a buildLabelPrefix property in the definitions


Thanks Nick. That would still require to have 2 build definitions, but it's good to know I can prepend some string to the date format of the snapshot using buildLabelPrefix. 

My main concern was not the snapshot, rather the email notification, my boss seems to think that a different title for the nightly/scheduled build would help attract attention of the developers (they must act if broken) compared to the intra-day/on-demand builds -- although I can probably see the argument that it should not make any difference, but sometimes the boss has different ideas.


Nick Edgar commented Aug 30 '13, 9:55 a.m.
JAZZ DEVELOPER

Currently you would need separate build definitions for their email notifications to be processed differently.  That would also allow different label prefixes, and different schedules.

We have enhancement request Template-based capability to format emails sent as build notification mails (198238) (see also others linked from its parent), but even a template-based approach would require some info to go on to distinguish continuous from integration builds.  The simplest way is to have separate definitions, but I acknowledge that that may not fit everyone's practices. 

Your answer


Register or to post your answer.