Jenkins jobs can trigger other Jenkins jobs upon their completion, creating automated build pipelines.
Let’s say you have a "Build" job that compiles your code, and you want to automatically trigger a "Test" job immediately after "Build" successfully finishes. Here’s how you set that up.
First, navigate to the configuration page of your "Build" job. Scroll down to the "Post-build Actions" section.
Click the "Add post-build action" button and select "Build other projects."
In the "Projects to build" field, enter the exact name of the job you want to trigger. In our example, this would be "Test."
By default, this action triggers the downstream job regardless of the upstream job’s build status. To ensure the "Test" job only runs after a successful "Build," click the "Add" button next to the "Projects to build" field. This opens a dropdown where you can specify the conditions under which the downstream job should be triggered. Select "Trigger only if build is stable."
"Stable" in Jenkins typically means the build completed successfully without any errors or test failures. If your "Build" job fails, the "Test" job will not be triggered.
You can also specify a timeout for the downstream job. If the downstream job doesn’t start within this period, the upstream job will consider it a failure. This is useful for preventing build chains from hanging indefinitely.
The "Trigger other projects" post-build action is straightforward, but its power lies in orchestrating complex workflows. Imagine a scenario where a successful build triggers not just tests, but also a deployment to a staging environment, followed by integration tests, and finally, if all pass, a deployment to production. This chain can be built by linking jobs sequentially using this mechanism.
The critical component here is the explicit naming of projects. If the "Build" job is configured to trigger a project named "Test," and you later rename "Test" to "QA Tests," the trigger will break. Jenkins won’t automatically know the new name. You’ll need to go back into the "Build" job’s configuration and update the "Projects to build" field.
Another common pitfall is circular dependencies. If Job A triggers Job B, and Job B also triggers Job A, you’ll create an infinite loop, potentially overloading your Jenkins controller and agents. Jenkins has some built-in protections against immediate circular triggers (e.g., A triggering B, and B immediately triggering A), but more complex indirect loops can still occur. Always visualize your build pipeline to avoid these.
You can also trigger jobs based on specific SCM changes. For example, you might only want to run tests if code in the main branch has changed. This can be configured within the downstream job itself, using its "Build Triggers" section, often in conjunction with SCM polling or webhook configurations. The upstream job then acts as a gatekeeper, ensuring only relevant builds proceed.
The "Build other projects" action also allows for parameter passing. If your downstream job requires parameters (e.g., a build number, a specific version tag), you can configure how these are passed from the upstream job. This is crucial for making your pipelines dynamic and adaptable. You can choose to pass parameters explicitly, or inherit them from the upstream build.
Beyond simple sequential triggers, you can also build fan-out and fan-in scenarios. A single successful build can trigger multiple independent jobs (fan-out), and then a subsequent job can wait for all of those to complete before proceeding (fan-in). This is managed by having multiple "Build other projects" actions in the upstream job and by configuring the downstream jobs to wait for their upstream dependencies.
The next step in orchestrating build pipelines is to explore more advanced workflow management tools like Jenkins Pipeline (using Jenkinsfile) which offers more programmatic control over complex job dependencies, conditional execution, and parallel execution.