It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,787
×10,826

question asked: Apr 17 '18, 11:17 p.m.
question was seen: 1,592 times
last updated: Apr 30 '18, 6:12 p.m.

Related questions

FAQ - How this Forum works

Deliver participant to start a build and wait for it to finish

0
Ernest Crvich (192●1●19●19) | asked Apr 17 '18, 11:17 p.m.

I've found a fair bit of help online for creating a basic participant that can automatically start a build when someone delivers to a stream (I'm doing this as a Phase 2 deliver participant), but what I can't seem to do is have the participant wait for the build to complete. The idea is to prevent the delivery from completing if the build fails. But if I try to start the build immediately (setStartBuild(true)) by forcing it to use a particular build engine (not something I want to have to do, but the API seems to require that), I get this error:

Illegal transaction in progress for service method call.

If I don't start the build myself, then when I get in a loop and wait for the BuildResult to move to a finished state, it never does, and when I refresh the Builds view for the build definition involved, the build request never even shows up in the queue. It's almost like the deliver operation itself is preventing requestBuild from really doing anything.

I realize that a build is potentially long-running and may require configuring a longer timeout value in clients, but that is acceptable. The deliver itself runs in a background job, so the user's RTC client isn't frozen while the deliver is pending.

Is there any server-side way to do what we're after?

2 answers

Most liked answers|Newest answers ↑|Oldest answers

0
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Apr 21 '18, 8:46 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

The idea of a green stream is that you have your developers deliver to an intermediate stream where the continuous builds are running, and then the continuous build delivers to the "green stream" if the build succeeds.   That way there is no need to try to block the deliver, which would be a bad idea since the deliver is performed on the server, and you don't want all sorts of blocked delivery transactions accumulating on the server.
0
permanent link
Ralph Schoon (63.1k●3●36●46) | answered Apr 18 '18, 2:27 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

The concept is called "Gated Delivery".

As far as I can tell, we discussed and even implemented Gated Delivery for one customer. It was a custom implementation and did not get added to the product.

As far as I remember it was quite complicated for the very reason that you can not (and should not) wait blocking in a follow up action. the follow up action itself runs in the context of other DB transactions and should be executed as quickly as possible.

You have to find a way to detect a build has run for the specific configuration and then allow delivering.
There are a lot of other dependencies that make this quite complicated.

I think using a green stream is a far better concept. See https://jazz.net/library/article/649 . This allows you to have something in the green stream that works and builds. If someone messes up you can fix that.

Comments
Ernest Crvich commented Apr 18 '18, 11:30 p.m.

Interesting. Unfortunately letting bad code move into streams before asserting the code is good isn't so great because we're talking about use cases where "always moving forward" style development doesn't work well (due to unwanted file-level dependencies that would be injected). Literal removal of bad code from streams is often a major headache...whereas it's typically quite trivial from workspaces (Discard).

So I tried using a workspace variation of your suggestion...i.e., where each developer has their own "build workspace" that they deliver to (and then the build participant would start up a build, but not wait on it...if successful, it would deliver the code on to the stream). Unfortunately it doesn't look like RTC calls any advisors or participants for workspace-to-workspace deliveries...is that really true?! That would kill an otherwise pretty smooth solution to this problem.

Ralph Schoon commented Apr 19 '18, 2:17 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I think the concept we used back then was creating baselines/snapshots in the build and using that for the delivery. There are several things to consider especially permissions.

I would assume a delivery is a delivery. On the other hand A developer can have their own stream. Streams are cheap.

Ernest Crvich commented Apr 23 '18, 12:01 p.m.

Well, each developer can't realistically have their own stream, since streams aren't owned by individuals (only team areas or project areas). If a team of 100 devs all had their own stream, the list of streams under Source Control would be ridiculously cluttered. Whereas if users simply had their own build workspace, no one but them would even know about it.

So the "team stream" idea is ok but not great given the headache of true backouts customers will occasionally have to deal with. We'll proceed with this approach since it appears to be the only option, but it sure would be nice if participants were called for workspace-to-workspace deliveries. 8^)

Geoffrey Clemm commented Apr 30 '18, 6:12 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Since a workspace is owned by a user, not a process area, what process area would be used for a workspace delivery participant? 

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.