CODEWITHSUNDEEP
hudson
kukudas
kukudas

Reputation: 4934

Hudson executing upstream project when downstream project is triggered

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

Upvotes: 1

Views: 718

Answers (4)

Cam Jackson
Cam Jackson

Reputation: 12294

Perhaps you could add an extra file into the repository of A, and somehow ensure that whenever code is committed to B, this file is modified in some way? Also, enforce a quiet period for B. This way A will always build before B.

Upvotes: 0

Cam Jackson
Cam Jackson

Reputation: 12294

Another possibility: you could add some shell script to the config of B that manually triggers A, unless this build was triggered by A.

First make it check what triggered the build. I'm not sure if there is a 'proper' way to get this information, but here's one way. Read the build.xml file (under jobname/builds/jobnumber/), and look for this stuff:

Triggered by SCM:

<hudson.model.CauseAction>
    <causes>
        <hudson.triggers.SCMTrigger_-SCMTriggerCause/>
    </causes>
</hudson.model.CauseAction>

Triggered by another job:

<hudson.model.CauseAction>
    <causes>
        <hudson.model.Cause_-UpstreamCause>
            <upstreamProject>agp_lib_V5</upstreamProject>
            It goes further than this but that's all you need.

Once you know what triggered the build of B, you can then either trigger a build of A and quit (for SCM-triggered builds) or continue on with the build as normal (for upstream-triggered builds).

It's not pretty, but it could work.

Upvotes: 0

Peter Schuetze
Peter Schuetze

Reputation: 16305

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.

Upvotes: 0

Peter Tillemans
Peter Tillemans

Reputation: 35341

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.

Upvotes: 1

Related Questions