Is it possible to have two almost identical build definitions for a single work space repository?
![]()
Hi,
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
2 other answers
![]()
> 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.
|
![]()
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 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 :-)
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:
> 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.
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
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.