Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Build workspace access denied?

 we have a build farm, and have put all the build Engines in a separate project, open access, but with limited update permissions. 

we created some build def templates in that project so anyone needing to run a build uses one as a source into their project and adds their workspace, and special settings.. and off it goes.

but.. we have a problem 

I have a workspace, in my project, I want to run a build for one of the components. 
my workspace is owned by me, but public access..

the build ENGINES are owned by a generic build user service account. 
I am not a member of the build engine project, and my workspace is not scoped into the build engine project. 

when I submit the build, the service account user gets access denied trying to load from my workspace.
if I change the owner to the service account, it works fine. 

I don't see a permission on workspace read..see lots on write.. 

any pointers to places to read on how to resolve this?

0 votes


Accepted answer

Permanent link
the error.. 

com.ibm.team.repository.common.PermissionDeniedException: Permission denied. Only the owner of the repository workspace 'SamD's workspace' can modify it.

this may be because of the snapshot 

| update, it was the default 'Accept Changes from the stream'

I don't want the stream level changes, this is really a personal build. 
(the setting was below the fold.. so I missed it)
Ralph Schoon selected this answer as the correct answer

0 votes


One other answer

Permanent link
I believe your Build Service Account should (besides the build system license) be a member of the project area you have your repository workspace, in order to be able to access the SCM data. This is how I have it set up  usually anyway.

0 votes

Comments

the build user IS a member of the project I am a member of.

workspaces do not have project scope unless requested.. mine has personal scope. 

Public visibility only provides read access.

Why does the build try to modify the repository workspace? The build should only load from it.

The build usually only does snapshots on 'public builds'.

 the build def says 'accept changes' which would modify the workspace..


what do you call public?  a build is a build. 
if this checkbox is on, then it WILL create a snapshot too

but this build is from my personal workspace.. 

Hi Sam, workspaces are writeable only by the owner, so it needs to be owned by whichever user is doing the accept. e.g. in JBE usage the user given on the JBE command line also needs to own the build workspace, except for personal builds where no mod is done.  The user must also have visibility to the build, which they always would if they're the owner. For personal builds, the workspace visibility either needs to be public, or scoped to project area, where the JBE user is also a member of the project. Note that workspaces are created with private visibility by default, except when created via the build definition SCM page in which case they're public.

thanks.. I don't see a personal build checkbox anywhere (4.0.4) 

I thought I did on my home system (4.0.5)  

The personal build option is in the RTC build request dialog, if the definition is configured for Jazz SCM. If using Hudson/Jenkins, personal builds cannot currently be initiated from that side, though we have an enhancement request open for that.

 thanks!  knew I saw it somewhere

showing 5 of 7 show 2 more comments

Your answer

Register or log in to post 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.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,019
× 562

Question asked: Mar 07 '14, 8:51 a.m.

Question was seen: 7,138 times

Last updated: Mar 10 '14, 1:28 p.m.

Confirmation Cancel Confirm