Built toolkit to support building products under RTC control
I have customer who have "products" under RTC control and would like to use the build toolkit ant task to support it. This assumes that there are development and integration streams and appropriate workspaces defined/configured.
1. Integraiton accept dev changes. 2. fetch code 3. build 4. put newly build products back into int stream via changeset and check ins 5. baseline and publish all changesets associate with this build Multiple baselines are acceptable but only the last one from step 5 should be usable by dev. All "unpublished" baselines should be for reference only. The final published list of change sets must include all used in the build. Should the build itself fails, then all "accepted" changeset must be marked available for next integration build run. The description of teamAccept is very terse and not very informative on whether a baseline/snapshot is created if "snapshotname" is not supplied. How to 'discard' a 'bad' baseline is also not well defined in RTC. What happens to changeset accepted into a "bad" baseline? Assuming my customer decides not to use "teamAccept" what is the best way of finding all change sets accepted (assuming using "scm accept"). My customer runs a windows shop and will only contemplate parsing any output using java/ant/visual basic. NO PERL/BASH etc. |
One answer
I suggest:
1. set up the build definition's SCM configuration as usual: * with a dedicated build workspace that has the integration stream as its only flow target (don't specify the stream directly) * don't share the build workspace across different build definitions * the build workspace must be owned by the user under which JBE and the Ant tasks run 2. use JBE to do the accept/fetch if possible. You can use the teamAccept / teamFetch tasks if needed, but it's simpler to let JBE do it. If using teamAccept, specify a snapshotName property, e.g. <teamAccept ... snapshotName="${buildDefinitionId}_${buildLabel}"/> 3. configure the build definition's Ant configuration to run your Ant script (as usual) 4. to deliver extra changes back to the stream, invoke the SCM CLI from the Ant script, e.g.
5. to create a snapshot, use the scm create snapshot command, which will create baselines for the affected components as needed:
Where you supply the workspaceName property. If using JBE to do the accept/fetch, you can use ${team.scm.workspaceUUID} instead of ${workspaceName}. To avoid having to specify the password in the script, you can do an 'scm login -r {repo} -u {userId} -c' once on the build machine(s). It will prompt for password then remember it for subsequent uses of the SCM CLI with that repository. In that case you don't need to specify -u or -P in the script. -r isn't really even needed since it can infer that from the metadata for the loaded workspace. The '-u y' and '-a n' after the scm command indicate that it should output item references as UUIDs instead of short decimal 'aliases'. '--non-interactive' ensures that it does not hang waiting for user input, e.g. it won't prompt for a password. After step 5, there will be two snapshots: (a) the one made by JBE or the teamAccept task, and (b) the one created in step 5. Only the latter contains the extra change set(s) with the changes checked in by the build. There's no way, currently, of overriding the first snapshot, however you could publish a link to this snapshot using the linkPublisher Ant task. e.g.
Where the value of the snapshotUUID is obtained from the output of the scm create snapshot command. This snapshot link will show up on the External Links tab of the build result. |
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.