It's all about the answers!

Ask a question

Permission denied while invoking post-build participant


Makson Lee (41024141) | asked Feb 01 '12, 8:16 p.m.
Hi All,

We want to promote snapshot (or deliver baseline) from build workspace to target stream automatically, so we have the post-build deliver set in the build definition, but got the following error while a build was executed, at the moment, we found that there is just one baseline in the build workspace needed to delivered, so why a 'save stream' permission is needed?

2012-02-02 04:57:13 Invoking post-build participant "com.ibm.team.build.autoDeliver"
2012-02-02 04:57:13 Delivering components...
com.ibm.team.repository.common.PermissionDeniedException: 'Save Stream' failed. Permission denied.

Regards,
Makson

15 answers



permanent link
David Lafreniere (4.5k7) | answered Feb 02 '12, 1:59 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
As i said in earlier post, build engine try to do the 'replace' action instead of 'deliver', is this a bug?

Regards,
Makson


This is actually accurate, it needs to perform a component replace and not a deliver of change sets / components. This is also similar to what happens in the pre-build "Jazz Source Control" participant. Semantically, this stage 'accepts' from the build repository workspaces' flow targets, however it actually performs a replace. (doing so avoids issues with deletions/discards/synchronization issue/etc.) For example, the build workspace could not blindly accept change sets as it's possible they might result in a conflict with what's already in the build workspace, and obviously an automated build cannot 'correctly' merge conflicts. The main idea in both cases is that we need to put the source (pre-build accept) or target (post-build deliver) in the exact same state as the current state of the 'sources' (flow target / deliver stream) at the time of build.

For example, this allows the "Post-build Deliver" participant to have a stream mirror exactly what was built in the build workspace (by choosing "all components" in the "Post-build Deliver" page) What will happen is that the pre-build SCM stage will create a snapshot, and then the post-build stage will replace all components in that target stream with the contents of the created snapshot, ensuring the stream contains exactly what is in the snapshot created during the build (no more, no less)... this also ensures that the target stream is 'green' (assuming the "Trigger Policy" on the "Post-build Deliver" page was set to "Deliver if build has no errors or warnings").

permanent link
David Olsen (5237) | answered Feb 01 '12, 9:53 p.m.
JAZZ DEVELOPER
On 2/1/2012 5:23 PM, cdlee wrote:
We want to promote snapshot (or deliver baseline) from build workspace
to target stream automatically, so we have the post-build deliver set
in the build definition, but got the following error while a build
was executed, at the moment, we found that there is just one baseline
in the build workspace needed to delivered, so why a 'save stream'
permission is needed?

2012-02-02 04:57:13 Invoking post-build
participant "com.ibm.team.build.autoDeliver"
2012-02-02 04:57:13 Delivering components...
com.ibm.team.repository.common.PermissionDeniedException: 'Save
Stream' failed. Permission denied.

Delivering changes to a stream, whether it is in the form of change sets
or a baseline (even an empty baseline), requires modifying, and
therefore saving, the stream.

I don't know whether it is the build account or the user requesting the
build who needs permission to save the stream. (Since the Jazz build
engine seems to be initiating the deliver, I assume it is the build
account.) Whichever account it is, that account needs to have
permission to save the stream to which the changes are being delivered.

--
David Olsen
IBM Rational
Beaverton, Oregon

permanent link
Geoffrey Clemm (29.5k23035) | answered Feb 01 '12, 11:38 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The build account is executing the post-build participant, so it is the
build account which needs to have save-stream permission.

Cheers,
Geoff

On 2/1/2012 9:44 PM, David Olsen wrote:
On 2/1/2012 5:23 PM, cdlee wrote:
We want to promote snapshot (or deliver baseline) from build workspace
to target stream automatically, so we have the post-build deliver set
in the build definition, but got the following error while a build
was executed, at the moment, we found that there is just one baseline
in the build workspace needed to delivered, so why a 'save stream'
permission is needed?

2012-02-02 04:57:13 Invoking post-build
participant "com.ibm.team.build.autoDeliver"
2012-02-02 04:57:13 Delivering components...
com.ibm.team.repository.common.PermissionDeniedException: 'Save
Stream' failed. Permission denied.

Delivering changes to a stream, whether it is in the form of change sets
or a baseline (even an empty baseline), requires modifying, and
therefore saving, the stream.

I don't know whether it is the build account or the user requesting the
build who needs permission to save the stream. (Since the Jazz build
engine seems to be initiating the deliver, I assume it is the build
account.) Whichever account it is, that account needs to have permission
to save the stream to which the changes are being delivered.

permanent link
Makson Lee (41024141) | answered Feb 01 '12, 11:39 p.m.
We don't grant any 'save stream' privileges to our users, but they can still deliver change & baseline from workspace to stream.

On 2/1/2012 5:23 PM, cdlee wrote:
We want to promote snapshot (or deliver baseline) from build workspace
to target stream automatically, so we have the post-build deliver set
in the build definition, but got the following error while a build
was executed, at the moment, we found that there is just one baseline
in the build workspace needed to delivered, so why a 'save stream'
permission is needed?

2012-02-02 04:57:13 Invoking post-build
participant "com.ibm.team.build.autoDeliver"
2012-02-02 04:57:13 Delivering components...
com.ibm.team.repository.common.PermissionDeniedException: 'Save
Stream' failed. Permission denied.

Delivering changes to a stream, whether it is in the form of change sets
or a baseline (even an empty baseline), requires modifying, and
therefore saving, the stream.

I don't know whether it is the build account or the user requesting the
build who needs permission to save the stream. (Since the Jazz build
engine seems to be initiating the deliver, I assume it is the build
account.) Whichever account it is, that account needs to have
permission to save the stream to which the changes are being delivered.

--
David Olsen
IBM Rational
Beaverton, Oregon

permanent link
Makson Lee (41024141) | answered Feb 02 '12, 1:07 a.m.
I found that he permission 'Replace components in the stream' is what we need to grant to build account, and in the history view of stream baseline, lot of baselines named 'Backup before replace' are there.

But why? Not delivering changes & baselines from build workspace to target stream? This would confuse us ....

permanent link
David Olsen (5237) | answered Feb 02 '12, 1:08 a.m.
JAZZ DEVELOPER
On 2/1/2012 8:53 PM, cdlee wrote:
We don't grant any 'save stream' privileges to our users, but they can
still deliver change& baseline from workspace to stream.

(That's what I get for replying without doing my homework first.)

I don't know why the post-build deliver operation needs 'save stream'
permission rather than (or in addition to?) 'deliver' permission. I
don't know enough about that feature to answer. (I couldn't find any
real documentation about post-build deliver. I created defect 194215 to
fix the documentation.) I think someone from RTC Build will have to
answer this.

If your build account has a role that regular users don't have, you
could give 'save stream' permission to that role without giving too much
permission to all the normal people.

--
David Olsen
IBM Rational
Beaverton, Oregon

permanent link
Makson Lee (41024141) | answered Feb 02 '12, 1:25 a.m.
As i said in earlier post, build engine try to do the 'replace' action instead of 'deliver', is this a bug?

Regards,
Makson

permanent link
Makson Lee (41024141) | answered Feb 02 '12, 8:31 p.m.
Hi,

Thanks for your explaination, but should we change the 'Post-build Delivery' to 'Post-build Replacement', it is quite different between delivery and replacement.

As i found in this forum, someone just wanted to deliver baseline made in the build workspace after a successful build automatically, then someone told him the 'Post-build Delivery' would meet his requirement.

Ok, let's think about this case, if someone deliver another change to the stream during the build process, then what would happen if a 'Post-build Delivery' is triggered? The change would be discarded, that is not what we expect for post-build 'delivery'.

Regards,
Makson

permanent link
Geoffrey Clemm (29.5k23035) | answered Feb 02 '12, 9:23 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I personally would want to have the post-build deliver action be a
standard "merge" deliver, and not a "replace". Either there is nothing
to overwrite, in which case "merge" will succeed, or there is something
that will be overwritten, in which case I would think the usual intent
would be to fail the deliver, rather than overwrite. I've submitted
work item 194461 for this. Please feel free to add a comment to
indicate your interest/support.

Cheers,
Geoff

On 2/2/2012 2:08 PM, daviddl wrote:
cdleewrote:
As i said in earlier post, build engine try to do the 'replace'
action instead of 'deliver', is this a bug?

Regards,
Makson

This is actually accurate, it needs to perform a component replace and
not a deliver of change sets / components. This is also similar to
what happens in the pre-build "Jazz Source Control"
participant. Semantically, this stage 'accepts' from the build
repository workspaces' flow targets, however it actually performs a
replace. (doing so avoids issues with
deletions/discards/synchronization issue/etc.) For example, the build
workspace could not blindly accept change sets as it's possible they
might result in a conflict with what's already in the build
workspace, and obviously an automated build cannot 'correctly' merge
conflicts. The main idea in both cases is that we need to put the
source (pre-build accept) or target (post-build deliver) in the exact
same state as the current state of the 'sources' (flow target /
deliver stream) at the time of build.

For example, this allows the "Post-build Deliver"
participant to have a stream mirror exactly what was built in the
build workspace (by choosing "all components" in the
"Post-build Deliver" page) What will happen is that the
pre-build SCM stage will create a snapshot, and then the post-build
stage will replace all components in that target stream with the
contents of the created snapshot, ensuring the stream contains
exactly what is in the snapshot created during the build (no more, no
less)... this also ensures that the target stream is 'green' (assuming
the "Trigger Policy" on the "Post-build Deliver"
page was set to "Deliver if build has no errors or
warnings").

permanent link
David Olsen (5237) | answered Feb 02 '12, 11:53 p.m.
JAZZ DEVELOPER
On 2/2/2012 5:38 PM, cdlee wrote:
Ok, let's think about this case, if someone deliver another change to
the stream during the build process, then what would happen if a
'Post-build Delivery' is triggered? The change would be discarded,
that is not what we expect for post-build 'delivery'.

I had the same thought. If the post-build deliver is really a replace,
then the target stream cannot be the same stream from which the build
workspace accepts changes. It needs to be a separate stream that
normally gets changes only from the build, not from developers.

--
David Olsen
IBM Rational
Beaverton, Oregon

Your answer


Register or to post your answer.