It's all about the answers!

Ask a question

How to automatically deliver the changes to stream1- stream2?.


amarpreet singh (13) | asked Sep 09 '15, 3:41 a.m.

How to automatically deliver the changes to stream1- stream2?.

I have set the "flow target" as stream1 in stream1 view. But all the changes are going to outgoing folder in stream1. I am  manually  delivering the changes to stream2.


Comments
Geoffrey Clemm commented Sep 11 '15, 10:33 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

If by "automatic", you mean that every time a change set is delivered to stream1, it is automatically delivered to stream2, then that is not supported.   If you described why you wanted to do this, we might be able to provide an alternative implementation.


Arun K Sriramaiah commented Sep 14 '15, 5:18 a.m.

Hi Geoffrey,

Can you please give more details, why its not possible.is there any specific reason.

Regards,
Arun.


amarpreet singh commented Sep 14 '15, 5:27 a.m.

Build definition lock or block the deliver operation from other workspace while the build is running. <o:p> </o:p>

So I am using two steam structure as off now in my project one for BUILD & one for Development. <o:p> </o:p>

From development to BUILD stream auto deliver the code. <o:p> </o:p>


Geoffrey Clemm commented Sep 14 '15, 8:41 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I'm not aware of a build definition locking or blocking the deliver operation from other workspaces while the build is running.   What makes you believe it does?


amarpreet singh commented Sep 14 '15, 9:32 a.m.

When build is running using JBE (JAZZ Build Engine), all the changes delivered by developer during this time goes to “outgoing” folder. Developers are not getting any error while delivering but changes are not getting deliver to steam from workspace. <o:p> </o:p>

Most of our Team Members are  facing this issue now –Developer  delivers   code from “Outgoing” folder and he receives acknowledgment mail from Jazz Build  that delivered code has been successfully picked by Jazz build  .After some time automatically  again the same set of files comes under “Outgoing” Folder in RTC <o:p> </o:p>


Geoffrey Clemm commented Sep 14 '15, 3:02 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

See my warning below Arun's answer.   I predict that you have "Post-Build Deliver" turned on for your build, and it is overwriting the changes delivered by the developers.   You should turn off "Post-Build Deliver", and instead, have the last step of your build invoke the scm command line deliver operation (which is a real deliver, unlike the Post-Build Deliver, which is a replace operation).

showing 5 of 6 show 1 more comments

One answer



permanent link
Arun K Sriramaiah (3.2k13177) | answered Sep 09 '15, 4:20 a.m.
Hi Amarpreet,

You can use the "Post-build Deliver" option in Build Definition, Please find the link below and let me know does that help.

https://jazz.net/library/article/649

Regards,
Arun.


Comments
Geoffrey Clemm commented Sep 14 '15, 8:51 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Note that you should never use the "Post-build Deliver" option, unless you are sure that the build is the only process that will deliver changes to the stream.   This is because it actually isn't a "Post-build Deliver" option (even though that is what it is misleadingly called :-), but rather a "Post-build Replace" option ... i.e. it replaces the configuration of the stream with the configuration of the build workspace.   That means that all changes delivered to the stream since the build began will effectively be "backed out" from that Post-build action.  
The safest thing to do is to just invoke the Deliver operation via the scm command line as your final build step when the build succeeds.


amarpreet singh commented Sep 21 '15, 2:31 a.m.

Can you give more information on the Post deliver part.... It's hitting my team.



Ralph Schoon commented Sep 21 '15, 3:07 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

The stream to deliver to is supposed to contain builds that succeeded only. This stream should only be delivered to by the build.

Delivery between streams only works, if there are no conflicts. So you can't safely deliver from multiple sources to a post-build deliver stream.

If you have multiple builds, they need to deliver to their own post-build-deliver streams. If you want to integrate these streams, a user has to do so with a repository workspace. The integration must not be delivered to the post-build-deliver streams. Instead you would deliver the integration to the development streams. The result will end up in the post-build deliver stream after the integration was successfully built.


Geoffrey Clemm commented Sep 21 '15, 6:37 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Note that the key point here is that the current "post-build-deliver" function only works if only this build can deliver to the stream.   In my view, it would be very reasonable to allow both the build and users to be delivering in parallel to the same stream (in case you only want the checking done by the build for some changes, and not all changes), but that cannot be done with the current "post-build-deliver" function (which is really a "post-build-replace" function).   Please feel free to vote up An option for Post-Build Deliver step to do a deliver and not a replace (298057) if you want a real "post-build-deliver" function.


Ralph Schoon commented Sep 21 '15, 6:59 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Any delivery from two sources can lead to conflicts. Conflicts can not (usually) be resolved automatically. Hence I am very skeptic if this would always work.


Geoffrey Clemm commented Sep 21 '15, 7:13 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

When there is a conflict, it is reported by the build, and the user resolves the conflict as usual.   It just automates the common case where there are no conflicts.

showing 5 of 6 show 1 more comments

Your answer


Register or 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.