Jenkins Partial Assembly / Modular Assembly on Commit Hook

Question

Instruments:
Jenkins ver. 1.470
Maven 2
Subversion

Environment

Suppose my build has a number of AD projects. A dependency graph exists as shown. That is: B depends on the classes in A, C depends on the classes in B, D depends on the classes in A. We create jenkins assemblies so that they call the dependencies that depend on them, like the post-build action.

a
| → B → C
| → D

Every night we run a full build in Jenkins (A builds, triggers B (triggers C), triggers D). This is done fairly easily, telling A to build the night, and the rest of the cascades.

Problem

However, when fixing, we want to build projects that were fixed once.

• Situation 1: We conduct a survey of the repository (or use hook fixes , it does not matter) and find that there was a commit on B, then B will build and C will build. Success!

• Situation 2: We polled the repository and found that B and C were committed in the same commit, then Jenkins will try to build B (run build C) and build C (second build). Renouncement. . What's happening? C was built twice, taking up valuable construction time. Store assembly fast!

Does anyone know how to run only the highest project in each stream pipeline?

I believe that one solution will be a complex SVN hook that defines the highest project in every pipeline ...

• Case 3: Fix BC and D in one commit. The SVN hook believes that C depends on B. The hook calls up links to specific projects to start assembling for B and D.

Traps: A very complex SVN capture. Keep to support piping in the SVN hook.

I feel that this is a problem that others are facing. Is there a Jenkins plugin that helps with this?

Answer 1

It would be suggested that the Jenkins wait with the assembly until the assembly is complete, which depends on c. To do this, use the flag in the job configuration. But you have to do it for every job. Btw ... there is another flag that requires the jenkins to wait with the build until the dependent task is complete.

Answer 2

I am also looking for an effective solution to this problem. I saw several suggestions, but so far we have managed to avoid one of the errors by serializing the assembly using the Locks & Latches plugin. This does not prevent the project from creating several times from the same session, but it ensures that the project will be restored sequentially after the completion of the upstream project.

This is actually a difficult problem to solve in the general case, but I was thinking of writing a plugin to handle this. One simple solution is to simply check if the upstream project is being built now, and remove yourself from the build queue, if so. Since ascending work will begin with your assembly when it is complete, this is one option.

A better option would be a plugin that automatically manages the build queue based on your dependency graph. This can be tricky because you need to make sure that the build does not start until all its dependencies are complete. In essence, this means that each checkin will force the plugin to automatically add all subsequent assemblies to the queue so that it can manage them. This may be a smart and easy way to do this with existing upstream / downstream triggers, but it’s not yet clear to me how to do this. There are already ready-made plug-ins for the pipeline that claim to cope with this situation, but they obviously do nothing to prevent the race when the downstream assembly can be triggered by the same control as the upstream assembly.