Permission denied while invoking post-build participant
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
Ok, let's follow up in the work item. I would like to find a better way of dealing with deletions, and it would help to understand more about your scenario for that, so if you can provide more details in the work item that would help.
|
Hi Nick,
Yes, the delivery may take the discarded changes back, but one should know about this if he want a regular delivery. Just like that the replacement may accidentally remove changes if someone (me?) don't know about 'Post-build Delivery' exactlly. Please add a option to let us choose what we want to use. Regards, Makson |
> 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. Since the snapshot is taken at the time of the accept at the start of the build, there would be little benefit in pushing it back to the same stream. The target stream already has the changes. It could only lose changes. What are you really trying to do in this scenario? Is this the "run a personal build then deliver if OK" scenario? If so, we'd also need enhance it to support personal builds. The main issue with a regular deliver is the handling of discards and conflicts. In the work item Geoff filed he suggests simply failing the post-build deliver if there are conflicts. That doesn't seem unreasonable to me. But what about discards? Say a developer "delivers a discard" after the start of the build, i.e. discards one or more change sets from his workspace, then does a component replace on the target stream. How should this be handled in the post-build deliver? Like a regular developer workspace, the build workspace will see this as an outgoing change, so a regular deliver would put the changes back in the stream. It may be possible to take advantage of the snapshot taken at the start of the build in this case, e.g. to say "at the start of the build, these changes were in the stream, and now are not, so treat it as a discard and don't put them back", but that only works if the target stream is the same as the source stream. For the personal build case, we'd also need to allow personal builds to create a snapshot (item 193979). |
also, now i need to modify my build script to deliver baseline, but wait, baseline delivery is not supported by scm command ....
Regards, Makson |
If the post-build deliver is really a replace, then the only purpose for 'Post-build Delivery' is to make a green stream. Regards, Makson |
On 2/2/2012 5:38 PM, cdlee wrote:
Ok, let's think about this case, if someone deliver another change to 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 |
Geoffrey Clemm (30.1k●3●30●35)
| 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: |
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 |
As i said in earlier post, build engine try to do the 'replace' action instead of 'deliver', is this a bug?
Regards, Makson |
On 2/1/2012 8:53 PM, cdlee wrote:
We don't grant any 'save stream' privileges to our users, but they can (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 |
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.