Build Engine visibility
Posting this for a customer.
Similar to SCM Components ... Build Engines appear to have a global scope within a given RTC instance. They appear to be visible and available to all projects regardless if anyone on project is a member of the original project under which the build engine was defined. For example, we create a new build engine named "BUILDENGINE_1" under PROJECT_A. I associate this build engine with a build definition named "CI BUILD" for PROJECT_A. PROJECT_B creates a new build definition named "CI BUILD" and can see "BUILDENGINE_1" in the "Supporting Build Engine" list and is able to select it. PROJECT_B is now using PROJECT_A's build engine for its CI BUILD (and so on and so on). However "BUILDENGINE_1" only appears below PROJECT_A's Build Engines list. If this is true, it will be difficult for us to enforce the isolation of various project CI builds to designated build engines. Any recommendations on how to best handle / monitor? |
4 answers
There is a gap in the permission checking, but for the usual cases what you describe below should work. When you assign a build definition to a build engine, the build engine is permission checked. This means that as long as the users in PROJECT_A don't have permission to modify build engines in PROJECT_B, you can reserve a set of build engines for a particular project or team. Combine this with the permission settings for Request a Build, and you should be ok.
This however leaves the UI a bit confusing, in that it shows everything. We've been tracking this in https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=62147 Then there is a small problem with permissions, this isn't that big a deal because in the end you can control who can request builds against your engines using the request build permissions. https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=102354 Hope this helps. Jean-Michel |
We are using an LDAP-enabled RTC instance. We have a RTC project where the user who is assigned the "Administrator" process role on the project is unable to enter Scheduled Absences for the team members of the project. He is getting the message: "The user <id> is not authorized to perform the oper..."JazzAdmins" role is required to perform this operation.
1). Shouldn't he be able to do this type of activity with "Administrator" process role rights? He can add/remove members but is unable to enter their scheduled absences. 2). We cannot add this user to our JazzAdmins LDAP autogroup as this will give the user full admin rights across all RTC instances and truly seems like overkill for the issue at hand. 3). If being added to a group is required, then wouldn't JazzProjectAdmins suffice? Thank you, Tim Mulligan |
|
Jean-Michel - Thanks for this explanation. It helps. I'll get back if we have any further questions.
|
|
Please ignore. I had intended to start an entirely new/separate thread.
|
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.