Welcome to the Jazz Community Forum
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
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.
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 ?
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:
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:
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 ?
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.
Opened enhancement 103635
On 1/18/2010 9:38 AM, David Ward wrote:
On 1/18/2010 9:38 AM, David Ward wrote:
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:
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 ?
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.
David Ward wrote:
I don't think that information is available to the build script.
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.
How should my build script determine:
1) The user who requested the personal build ?
I don't think that information is available to the build script.
2) The workspace that the user specified for the personal build ?
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.
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
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:
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:
How should my build script determine:
1) The user who requested the personal build ?
I don't think that information is available to the build script.
2) The workspace that the user specified for the personal build ?
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.
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
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.