Why does a build engine need a Project or Team area?
What is the purpose of the build engine's Project or Team Area specification?
I configured build definitions for two teams. Both share the same build engine and associated jbe instance. (And have the same build user declared as a team member.) However the build engine indicates only one of the teams in the Project or Team Area specification field. So why is it there and what uses the team specification? |
4 answers
On 13-Jan-10 8:07 PM, jim.islandtraining.com wrote:
What is the purpose of the build engine's Project or Team Area I think it is used for permission control. Everything in RTC is owned by something. In your case, th engine is owned by Team A although because you haven't restricted access it can be also used by Team B. Regards, Chemi. |
On 13-Jan-10 8:07 PM, jim.islandtraining.com wrote: What is the purpose of the build engine's Project or Team Area I think it is used for permission control. Everything in RTC is owned by something. In your case, th engine is owned by Team A although because you haven't restricted access it can be also used by Team B. Regards, Chemi. I don't think using a build engine can be restricted with permissions, and access control is applied at the project level not the team level. So I guess I can stop another project from using my team's build engine, but don't see how to stop another team in my project from using it. In my case I actually want the teams to share the engine, but am trying to understand ownership and possible restrictions that could come up |
jim.islandtraining.com wrote:
I don't think using a build engine can be restricted with permissions, The team that owns the build engine controls who is allowed to modify the build engine. You have to modify the build engine to associate it with a certain build definition. So you can't prevent users in the same project from being able to know that your build engine exists, or from being able to see what builds are running on that build engine. But you can prevent users from running arbitrary builds on your build engine. |
Hi Jim,
The build engine's process area controls permissions for operations affecting the engine itself, before a build definition comes into play. The main operation is 'Control the Build Lifecycle', which is used when JBE requests the next build. JBE also needs permission to Save Build Engine, e.g. to update its last contact time and other info. It also controls who can modify the build engine, e.g. its id, the active/inactive flag, and the list of supported build definitions. Although the engine/definition mapping can be changed via either the build engine editor or the build definition editor, it's the engine that maintains the mapping, so its process area governs the permissions. Note that process permissions are looked up starting at the given process area and looking up its parent chain. Permissions may be overridden at the team area level, so different teams within the same project may have different permissions. Also note that the permissions are looked up for a particular user (i.e. the user running JBE or the Ant tasks), they're not defined directly for the engine itself. For example, if you wanted to prevent team A's engine from processing requests for team B, then you would define two build users, bobA and bobB, and two engines, engineA and engineB (associated with teamA and teamB respectively), with bobA granted the relevant permissions in teamA, but not teamB, and the opposite for bobB. When running the two JBEs, one would specify -userId bobA -engineId engineA, and the other would use bobB and engineB. The build user(s) should also have permission to modify the build definition(s) for the relevant engine(s), since after the build request has been determined, it's the process area for the build definition that governs all further operations for the build (updating its state and status, contributing downloads/logs, etc.) and the definition itself (updating the average build time once the build is complete). Hope this clarifies, Nick |
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.