Personal Builds and build properties
Personal builds a really useful, but I'm having trouble managing them.
There seems to be some important info missing (or that I can't find) from the default build properties, when personal builds are being used. How should my build script determine: 1) The user who requested the personal build ? 2) The workspace that the user specified for the personal build ? These two items would allow my build to include the user's name and workspace name in the build package filename or encoded within the build package itself. Knowing the workspace name is also interesting because .. maybe the jbe's local load path could include that workspace name so that different types of builds go into different local paths on the jbe machine. P.S. There's a workspace UUID in there but I think its referring to the build definition workspace and in any case, I don't know how to resolve a workspace UUID to a workspace name Any help appreciated Dave |
5 answers
There seems to be some important info missing (or that I can't find) from the default build properties, when personal builds are being used. I'm not sure about #2, but users can manually provide properties via the Build Properties subsection on the Request Build dialog. We have one reserved for ant launching options, in case they want verbose output or anything else. There's a Properties tab in the Build Definition editor that lets you preset some if that would make it easier for users to find. |
|
Yes, users can indeed provide properties.
I should probably open an enhancement request so that RTC itself will provide the userid and workspace information to the builds. Dave On 1/17/2010 8:22 PM, sbates wrote: David Wardwrote: |
|
Opened enhancement 103635
On 1/18/2010 9:38 AM, David Ward wrote: Yes, users can indeed provide properties. |
David Ward wrote:
How should my build script determine: I don't think that information is available to the build script. 2) The workspace that the user specified for the personal build ? In a personal build, the workspace UUID property is the UUID of the workspace being used for that particular build. It is not always the UUID of the workspace listed in the build definition. The workspace UUID property can be used to have the JBE keep the local copy of each workspace separate. For example, in our builds, the "Load directory" field on the "Jazz Source Control" tab of the build definition contains "/build/workspaces/${team.scm.workspaceUUID}" and the "Delete directory before loading" box is not checked. There is a problem with using the workspace name for anything important: the workspace name is not guaranteed to be unique. When you create a new repository workspace based on a stream, RTC suggests a workspace name that is not unique. |
|
I just opened an enhancement 103635 for this before I read your post.
That's interesting advice re:the workspace name. Yes, of course, the workspace name isn't unique. I had forgotten about that. I agree, that I could doing something similar to what you suggest re: the load path. The only difficulty (for us) is that there appears to be no way to relate a particular personal build package back to the requesting user. The workspace UUID's are unique but opaque ! Dave On 1/19/2010 3:37 PM, David Olsen wrote: David Ward wrote: |
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.