-
Improvement
-
Resolution: Unresolved
-
Major
-
Jenkins 2.7.2, Pipeline-Job 2.5
Maybe it's just me, but I think having a possibility on Pipeline and Multibranch Pipeline projects to block execution while up- or downstream-projects are building would be beneficial, especially when migrating existing installations (see my posts in stackoverflow and in Jenkins CI).
With Freestyle and Matrix projects there was the option of going to the "Advanced Project Options" and specify that the build should be blocked when upstream/downstream project is building. For Pipeline and Multibranch this option is unavailable, and I did not find a means of synchronizing a Pipeline/Multibranch project to existing freestyle/matrix projects without orchestrating this in another pipeline script. However, having to do that with an installation of about 400 inter-dependent projects is a huge block of work that has to be sorted out in one go. Having those "block when upstream/downstream project is building" options would allow for a gradual and smoother migration.
- depends on
-
JENKINS-29913 Generalize DependencyGraph to Job (or ParameterizedJobMixIn)
-
- Open
-
- relates to
-
JENKINS-52203 Provide a 'prerequisites' sections (like triggers) that allows blocking the execution of a job
-
- Open
-
[JENKINS-37718] Block Pipeline job while upstream or downstream projects are building
Volker Gimple
created issue -
| Component/s | New: pipeline-general [ 21692 ] |
| Component/s | Original: workflow-plugin [ 18820 ] |
| Labels | Original: blocking downstream pipeline upstream workflow | New: blocking downstream pipeline upstream |
Volker Gimple
made changes -
| Priority | Original: Minor [ 4 ] | New: Major [ 3 ] |
| Component/s | New: workflow-job-plugin [ 21716 ] | |
| Component/s | Original: pipeline [ 21692 ] | |
| Component/s | Original: workflow-multibranch-plugin [ 21465 ] |
| Labels | Original: blocking downstream pipeline upstream | New: blocking downstream upstream |
Volker Gimple
added a comment - Hi Jesse,
First of all: Thanks for looking into this!
What I can't get my head around is how to handle the problem of potential file overwrites without the ability to define mutually exclusive execution of different projects. Consider the simplified scenario where project A builds a shared object file and after a successful build stores the results (shared object file plus header file(s) to go with it) on a file server (simple file copy). Project B builds an executable that uses the shared object and header file(s) built and copied by project A. If I cannot make sure that project A and project B never build simultaneously it may (and therefore sooner or later will) happen that project A updates the files on the server while project B is accessing them. If that happens on a Linux node it'll lead to build errors in project B, while on a Windows node the deployment step of project A will fail.
The only real workaround I have found so far (except for merging project A and project B into one project - an approach that becomes less of an option if you have not just one but numerous projects of type A) is to split the definition of either project into one project project that holds the pipeline definition (but does not trigger on SCM changes or upstream builds) and define the build trigger(s), dependenc(ies) and synchronization responsibilities in a freestyle project that just triggers the pipeline project and blocks until its execution finishes. This works for me and the overhead caused by the additional freestyle project is manageable, it just feels like an unnecessary detour given the fact that in principle the blocking functionality is available on all the other project types.
Volker Gimple
added a comment - Hi Jesse,
First of all: Thanks for looking into this!
What I can't get my head around is how to handle the problem of potential file overwrites without the ability to define mutually exclusive execution of different projects. Consider the simplified scenario where project A builds a shared object file and after a successful build stores the results (shared object file plus header file(s) to go with it) on a file server (simple file copy). Project B builds an executable that uses the shared object and header file(s) built and copied by project A. If I cannot make sure that project A and project B never build simultaneously it may (and therefore sooner or later will) happen that project A updates the files on the server while project B is accessing them. If that happens on a Linux node it'll lead to build errors in project B, while on a Windows node the deployment step of project A will fail.
The only real workaround I have found so far (except for merging project A and project B into one project - an approach that becomes less of an option if you have not just one but numerous projects of type A) is to split the definition of either project into one project project that holds the pipeline definition (but does not trigger on SCM changes or upstream builds) and define the build trigger(s), dependenc(ies) and synchronization responsibilities in a freestyle project that just triggers the pipeline project and blocks until its execution finishes. This works for me and the overhead caused by the additional freestyle project is manageable, it just feels like an unnecessary detour given the fact that in principle the blocking functionality is available on all the other project types. 
Joshua Hoblitt
added a comment - I echo all of vgimple's comments. A synchronization primitive would be really useful.
Joshua Hoblitt
added a comment - I echo all of vgimple 's comments. A synchronization primitive would be really useful.
Unlikely to implement anything like this.