access to RTC parameters in ANT when building
Hi,
Is it possible to detect the userid and process role of the one who requested the build in the ANT-script? Thanks in advance. Regards, Bernd van Oostrum. |
6 answers
Hi Bernd. No, these are not currently exposed as properties (or in any other form) to the build script (whether Ant or other).
Feel free to open an enhancement request for this. If you do, please provide more context about your scenario. |
|
Actually, there's an existing request. I've cc'ed you, but if you could provide more details about how you would use this info, I'd appreciate it. Are you looking for all roles the user has (in the context of the process area associated with the build definition), or more precisely which role allowed them to request the build?
|
Actually, there's an existing request. I've cc'ed you, but if you could provide more details about how you would use this info, I'd appreciate it. Are you looking for all roles the user has (in the context of the process area associated with the build definition), or more precisely which role allowed them to request the build? Hi Nick, Thanks for your response! In the properties, it is possible to let certain roles do a build or not. However, I have multiple environments in only one engine. One of the environments should be accessible (execute the build) for all, the other only for very specific people (or even better, a dedicated role). In fact I first worked around this issue by using a dedicated project area, with a seperate engine with only one build environment. However, if I can detect which role requested the build, I can abandon it when needed. Regards, Bernd van Oostrum. |
|
If you really want to prevent certain builds from being run by certain users, it's easier to configure the permissions for the 'Request Build' operation on the build definition (or rather its process area) rather than the build engine.
Typically a different user, e.g. a 'build' user, is specified on the JBE command line, and so is subject to a different set of permissions than the requestor. While I agree that exposing the user id and role of the requestor would let you do extra checks at build time, you really want to give the user feedback as early as possible, i.e. when requesting the build. In the current design, you don't necessarily need to assign a different process area to the different build definitions to get different permissions; you could use different roles corresponding to the different classes of build definitions. e.g. 'canRequestSecureBuilds' or something. |
|
> In the current design, you don't necessarily need to assign a different process area to the different build definitions to get different permissions
Actually, sorry, that's incorrect. The same permissions will apply to all build definitions associated with a given process area. What I suggest is: - for unprotected build definitions, just associate them with your team or project area and grant permission for 'Request Build' to the appropriate role(s) - for protected build definitions: - associate them with a separate team area (this could be a child team area) - add only the users who can request builds to this team area - add the 'Restrict the Users Requesting a Build' precondition for the 'Request Build' operation to the Everyone role The precondition is an extra check, which occurs after the permission check. So even if the parent project/team area gives permission to 'Request Build', the precondition will limit it to only users listed explicitly as members of that team area. Preconditions are configured in the Operation Behavior section of the process configuration (just below Permissions) |
> In the current design, you don't necessarily need to assign a different process area to the different build definitions to get different permissions This sounds perfect to me. Thanks! |
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.