Block Build Final Project Plug-in

This plug-in allows a project to block when upstream or downstream projects are building. Jenkins already provides this functionality built-in, but it blocks on the entire pipeline. This plug-in allows an optional final project to be specified. This allows the project to block on part of the pipeline instead of the entire pipeline.

Example

The below pipeline will be used as an example:

This pipeline compiles, tests, and deploys. The testing is divided into two projects - cool-app-test-server-only and cool-app-test-server-and-client. When cool-app-test-server-only is kicked off, the new code is installed in the server workspace and server-side tests are run. cool-app-test-server-and-client starts a server using the workspace and resources from project cool-app-test-server-only, and then runs tests via the client. Two projects sharing workspaces and/or resources is not a good design and should be avoid whenever possible. But in this example, the two test projects having their own workspaces and resources is not practical because of financial and resource constraints, so they must share.

In this example, UserOne kicks off project cool-app-build and shortly afterwards, UserTwo kicks off cool-app-build.

Default Behavior

The default behavior is:

Time	UserOne	UserTwo
1	cool-app-build	queued
2	cool-app-test-server-only	cool-app-build
3	cool-app-test-client-and-server	cool-app-test-server-only
4	cool-app-deploy	cool-app-test-client-and-server
5		cool-app-deploy

UserOne and UserTwo end up running tests at the same time! At time period 3, UserOne is running cool-app-test-client-and-serve and UserTwo is running cool-app-test-server-only. Because both of the test projects share resources, there will test random test failures.

Lock

There are plug-ins that allow a project to acquire a lock when it starts and release the lock when it finishes:

Time	UserOne	UserTwo
1	cool-app-build	queued
2	cool-app-test-server-only	cool-app-build
3	waiting for lock	cool-app-test-server-only
4	cool-app-test-client-and-server	waiting for lock
5	cool-app-deploy	cool-app-test-client-and-server
6		cool-app-deploy

In this scenario, UserOne delivers its code to the test area and runs the server tests. Then UserTwo delivers its code to the test area and runs the server tests. But then UserOne runs cool-app-test-client-and-server, but UserTwo's code and resources are in that workspace, causing failures.

Jenkins Built-in Behavior

Jenkins already provides a mechanism to block a build when down stream or upstream projects are building. In cool-app-test-server-only:

In cool-app-test-client-and-server:

Time	UserOne	UserTwo
1	cool-app-build	queued
2	cool-app-test-server-only	cool-app-build
3	cool-app-test-client-and-server	queued
4	cool-app-deploy	queued
5		cool-app-test-server-only
6		cool-app-test-client-and-server
7		cool-app-deploy

With this approach, we get the desired behavior that only one user is running projects cool-app-test-server-only or cool-app-test-client-and-server at a time. Also, once a user starts running the test projects, both tests projects are completed before the next user can run tests.

The drawback to this approach is the entire pipeline following the tests is also blocked. UserTwo must wait for UserOne's cool-app-deploy project to finish. UserOne should be able to deploy while UserTwo is running tests. This example pipeline is very small. Imagine a pipeline with 10 projects after the test projects - very inefficient.