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:
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:
The input of the build stage will include the commits in the pull or merge request.
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:
The status updates as the stage executes and completes.
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.