How can I share the same build engine with lots of users?
Hi
I'm sorry if this is a stupid question and perhaps has been answered many times but I can't find any specific mention of this in the forum or other articles. I've set up a Build Engine with a Jazz Source Control component to fetch files out of RTC via a repository workspace. It runs perfectly against a repo workspace that the userid running the build engine owns (I remember reading that the userid used to start the build engine must own the repo workspace) However, when I want to run a Private Build and substitute a repo workspace that I (or other people) own, it fails with access violation errors. Basically it does not have permissions on the repo workspace I have provided I want to share a Build Engine so that my developers can run personal builds before they deliver using the same Build Definition but does this mean every user has to run their own Build Engine to satisfy the permission requirement? I'm sure I'm missing something so if anyone can steer me in the right direction I'd be very grateful Thanks David |
7 answers
Ralph Schoon (63.2k●3●36●46)
| answered May 29 '12, 8:47 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi,
the users repo workspace visibility can't be private. It must be public or scoped, so that the build user has read access to it. At least that is what I think is the reason. |
Hi, Hi, Ralph Thanks so much for this advice. I've certainly moved 1 step forward and now I can get the build to at least fetch the code. The one thing that's still not working is the Jazz Source Control option in the Build Def to "Accept latest changes before loading". Not surprisingly I guess, this is issuing a permission error. com.ibm.team.repository.common.PermissionDeniedException: Permission denied. Only the owner of the repository workspace 'Dave Ds Development Stream Build Workspace' can modify it. Current owner is xxxxxxxxx and you are logged in as yyyyyyyy. If anyone has any tips to get around this then please let me know Thanks again, Ralph David |
|
Ralph Schoon (63.2k●3●36●46)
| answered May 29 '12, 10:12 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi David,
I have the following setup that works (the Money that Matters example) The build user has build system toolkit license (important) The Build user is a team member of the project (important) The Build definition uses a repository workspace that is owned by the build user (important) The other user (call him Ralph) is a developer and team member of the project. If Ralph has a scoped or a public repo workspace he can run private builds just fine. The build user can access the repo workspace of Ralph and use that data to build. Not sure what does not fit at your setup. Check who owns the streams and components. Check for the Buildsystem license. Check who is owner of the repo workspace that is used in the build definition. Check for permissions of the build user. |
|
Ralph Schoon (63.2k●3●36●46)
| answered May 29 '12, 10:19 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi David,
also, the Build user's repo workspace is "Public". |
Hi David, Hi again, Ralph I'll check the things you mentioned but meanwhile, can you just confirm that your build definition has the option "Accept latest changes before loading" ticked on the Jazz Source Control page and in your build log the step stating "Accepting changes into workspace " This is the bit that is currently not working for me Thanks David |
|
Ralph Schoon (63.2k●3●36●46)
| answered May 29 '12, 12:41 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Hi David, Hi again, Ralph I'll check the things you mentioned but meanwhile, can you just confirm that your build definition has the option "Accept latest changes before loading" ticked on the Jazz Source Control page and in your build log the step stating "Accepting changes into workspace " This is the bit that is currently not working for me Thanks David Yes, both are set. The errors you have indicate some access issues. I would suggest to set up a test system (derby/tomcat) somewhere, so you can play around with it. Deploy the sample project shipped with the Lifecycle Project Administration application and look at it. Check ownership. You could also log-in ad build user and see if you can access the user's repository workspace (read). |
Hi David, Hi again, Ralph I'll check the things you mentioned but meanwhile, can you just confirm that your build definition has the option "Accept latest changes before loading" ticked on the Jazz Source Control page and in your build log the step stating "Accepting changes into workspace " This is the bit that is currently not working for me Thanks David Yes, both are set. The errors you have indicate some access issues. I would suggest to set up a test system (derby/tomcat) somewhere, so you can play around with it. Deploy the sample project shipped with the Lifecycle Project Administration application and look at it. Check ownership. You could also log-in ad build user and see if you can access the user's repository workspace (read). Hi, Ralph Just for info, I still can't get this to work. No matter what I do, when I select the option to Accept Incoming Changes into the workspace in the build definition, all builds fail if the user that is running the build engine does not also own the associated workspace. This means I can control what repo workspace is used in a normal build and make sure it is owned by the build engine user but not for all the potential workspaces used in private builds. There seems no other way around it that I can see BTW, I'm currently using a sandbox project defined in the Jazz.net environment so version 3.0.1.1 client and server I hope to soon be able to access a 'real' environment so will re-test it on that Best regards David |
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.