Introduction
Recently, I stumbled upon an old SourceForge project I used to work on back in the early 2000’s, and quickly found myself battling back repressed memories of my first SVN experiences. It left me awestruck with the realization of how far source code management utilities have come, especially with the arrival of Git. Naturally with the driving mindset that became what we call DevOps today, Git was incarnated as a SaaS service; enter GitHub.
With a service like GitHub, the user experience is forgiving and enlightening as a terminal present user. When you look at Git’s ability to automate and innovate, the money is in the authors ability to script and code and the service provides API. Luckily, GitHub foresaw this, and their API proves it.
Level Up+
When you make changes to your code, you need to commit and push. This makes your changes official, and attributes those changes to you as an author. The workflow is pretty solid as a user, but as we mentioned earlier, automating this flow can have a few short comings. We need to automate the changes in your code, commit them, and push. This push though could be dangerous, as it instantly can make the changes available on a branch in your upstream repository.
This post is not about the right or wrong way to manage code. Every environment has their own requirements. It is about how to automatically create pull requests
We can take this one step further and use it for many purposes to create either gating mechanisms or to apply modifications to the code. A real world example of this could be the gofmt command, which applies stylization rules to a Golang source file. Once the changes are pushed to their own branch, we need to create a pull request so we can safely merge the changes into our master branch. This flow is common at organizations which require code reviews such as those that are subject to SOX compliance.# create_pr will generate a pull request via Github API
function create_pr() {
if [[ -z $1 || -z $2 || -z $3 ]]; then
echo "Please provide a message and/or branch"
exit 1
fi
repo=$1
branch=$2
message=$3# Add all the locally
git add .
# This will create the new commit to be merged
git commit -m "$message"# This creates the new local branch
git checkout -b pr/$branch# This pushes the local branch to the remote
git push -u origin pr/$branch
curl -XPOST -d '{"title":"${message}", "base":"master", "head":"pr/${branch}", "body":"${message}"}' \
https://api.github.com/repos/${repo}/pulls
exit 0
}
Usage of the above function would be:gofmt -w *.go && create_pr mikemackintosh/project "fmt" "Go formatting applied"
This would run gofmt in write mode, and if it was successful, it would create a pull request. This includes the committing of the code, creation of the branch, pushing of the branch and the creation of the pull request.
Conclusion
Keeping good software engineering practices at the forefront of the delivery pipeline is every engineering leaders dream. Taking effective patterns around workflows and automating them can increase morale and remove some of the unnecessary busy work from developer workflows.
With some good ‘ol DevOps intuition in our back pocket, we don’t fret and make the environment stressful. No! We wipe our brows and think about how a great engineering team with effective leadership turns these quarrels into conquerable challenges.
We like to solve the problem through automation, but keep the engineer in control.
Member discussion