Hudson executing upstream project when downstream project is triggered

tags:

hudson

views:

answers:

+1 Q:

Hudson executing upstream project when downstream project is triggered

Hi,

this seems like a simple thing but somehow i can't figure it out. I have a Project A and a Project B. If Project A executes successfully Project B is build. This works without a problem. If i want to execute only Project B i want that before it is build, Project A will be build again. Is this possible ? So basicly Project B should not run alone, it should always Project A build before. Thanks in advance.

kuku

+1 A:

The only reason I can imagine you want this kind of behavior is if you have some kind of circular dependencies. You really should try to get rid of these, as they will slow down development considerably going forward.

Anything which slows down the feedback loop costs a lot of money in lost productivity.

Peter Tillemans 2010-10-04 07:32:56

yeah i know that this is not optimal. But for now i have to do some compromise to ensure a stable build process. I know that i eventually have to break off this circular dependency.

kukudas 2010-10-04 07:45:06

I would configure hudson to build just project A using a timer like `5/30 8-18 * * *` to half 2 builds per hour during working hours of A and the project dependent on it. This is easy and avoids another tangled knot to untangle when the dependencies are resolved.

Peter Tillemans 2010-10-04 09:01:06

Well, it's not that simple. Project A has to be build when something changes in the repository. And after that Project B will be build. This works fine. But if someone triggers just Project B it will be build without Project A build before which can cause a Problem. If it is somehow possible to trigger Project A before Project B runs when triggering Project B this would solve the problem for now. I hope i could explain good enough. As i said this is not optimal, long term solution is that i'm able to run Project B alone without caring abount Project A.

kukudas 2010-10-04 11:01:05

Your explanation is clear. I was suggesting to disable the SCM triggered builds and only use scheduled builds in 30 minute intervals following a fixed pattern. It is not ideal, but it is repeatable and robust. If your code compiles fast, you can go to 15min or even 5min builds. From a developer POV it is transparent, other than the extra latency.

Peter Tillemans 2010-10-04 11:12:00

Unfortunately this is not an option for me. The Project B build process runs pretty long. Also the intention is not to run these builds often. They should just run when something changes in Project A but with the ability to run Project B alone as well if needed.

kukudas 2010-10-04 11:35:22

How about an easy solution. Trigger project A if there is a change in the repository for A or B. Project B will never be triggered by a SCM change, but always after A was build. This might cost you a little bit more space on disk and a little bit more time for checkout. But it is simple and straight forward. No timer, it will only build when triggered through SCM.

You could opt for shared workspace, but I would opt out from this option since you need to synchronize the two jobs, so that they never run in parallel. I would instead use the clone workspace plugin, to copy the workspace from A to B (you will only get the last one (by default, the last successful one), but you will get it even if there is a currently a new build.

Depending on who is responsible for the two projects (distinct teams or one team for both) you can also combine the two builds into one job.

Peter Schuetze 2010-10-04 15:46:58

ansaurus

tags:

views:

answers:

Hudson executing upstream project when downstream project is triggered

related questions