Pull Request Workflow With Snap CI
22 September 2015
Snap CI has had pull request integration with GitHub for quite some time now. In this article, we will revisit the workflow in more detail.
Pull requests are an excellent mechanism to collaborate on projects on GitHub. With a pull request, a developer makes changes on the clone of a repo or a branch and requests for the change to be merged to the master branch — thereby enabling the repository’s core committers to review the code change before accepting it.
Continuous Integration tools further augment this workflow. For e.g. Snap can be configured to execute builds for pull requests and reflect the status of the build GitHub Pull Request page. This is valuable feedback and gives confidence that the pull request can be safely merged to the master.
The pipeline has been modeled with three stages: Test (run unit and integration tests), Package (build and package a web application archive) and Deploy (deploy to AWS Elastic Beanstalk).
To enable pull request integration with GitHub, I click on the “Pull Request” link on the Settings page.
This takes me to the “Pull Requests Settings” page where I can configure the build stages that need to run to validate the pull request.
In above example, I want the Test and Package stages to be run so that I know that the application is in a clean slate.
I obviously don’t want the Deploy stage to be executed for pull requests, so I delete that stage from the pipeline configuration.
Apart from this, Snap also allows you to decide whether the secure files and environment variables configured for the master build should be applied to the “Pull Requests” build as well.
For pull requests from forked repos, Snap disables the option to copy configuration from master by default. This is because a malicious user can potentially expose the secure variables on your build.
Therefore, please be judicious when choosing to use the “copy configuration” option.
Let’s see what happens when I submit a pull request from GitHub. To do this, I first fork the example project.
After pushing my changes on the fork, I am now ready to submit a pull request.
After I create a pull request, note that GitHub starts showing information about pending checks — with a link to the Snap CI build for the pull request.
Clicking on the “Detail” link takes me directly to Snap’s pull request build page.
Note that the Pull Request pipeline can be re-run at any point. This is handy if the master has moved ahead before you merged the pull request and you want to re-validate the build against the current master revision.
Once the build completes, GitHub reflects the status of the build on the pull request page.
I now know that the pull request can be safely merged to the master!
This article is Part 1 in a series from our upcoming e-Book “CD with Snap CI”
comments powered by Disqus