Build from a Pull Request in the Continuous Delivery Pipeline

5 min read

By: Ritchie Schacher

Pull requests and continuous integration

Implementing the best practices

We are pleased to announce that you can now execute your Continuous Delivery Pipeline based on pull requests (GitHub), a.k.a merge requests (GitLab CE in IBM Git Repositories and Issue Tracking). You can use your pipeline to seamlessly and automatically build, deploy, and test new changes before promoting those changes to branches. This leads to a higher level of confidence and stability in your development stream and supports the overall best practices of Code Reviews, Continuous Integration, and Automated Testing.

Configuring pull request build triggers

When your pipeline is configured, you select the Git repository (repo) and branch as the input to your build stage:

Build Stage

The stage can be configured to run whenever a commit is pushed to the selected branch. You can now also select to run automatically when a pull or merge request is opened or updated or when it's closed:

Input Triggers

The input of the build stage will include the commits in the pull or merge request.

Git integration

When the pipeline executes, the status of each stage execution, along with backlinks to the execution record and log, is attached to the pull or merge request:

Git integration

The status updates as the stage executes and completes.

Protected branches

You can also take advantage of protected branches in GitHub and use required status checks to restrict merging unless the pipeline stages pass:

Protected branches

Stage organization

You can manage your pipeline in interesting ways, depending on your preference. For example, you may want to create two separate pipelines for a microservice: one pipeline for build-and-test and another for deploy-to-production. Or, you can keep all the stages in a single pipeline and set different inputs and triggers for separate build stages.

You might also want to have separate jobs for activities like setup or tear-down depending on whether the pull or merge request is opened or closed. For example, you could create separate build stages: one that triggers when a request is opened or updated, with a setup script, and another that triggers when a request is closed, with a teardown script.

Watch the demo

Watch this short video for a demo of building on a pull request and using a required status on a protected branch. The example uses separate pipelines for test and for deploy:

Try it out

Now you can try it out on your pipeline and get more value from pull and merge requests to encourage code reviews and validate changes. For more info, see our documentation. If you have questions or need help, feel free to interact directly with the development team in our Slack channel. We'd love to hear your feedback.

 

Be the first to hear about news, product updates, and innovation from IBM Cloud