On a day where GitHub is having a major outage, what better subject to write about than new GitHub features? So today’s subject is the new GitHub Actions and Suggested Changes introduced at GitHub Universe last week.
Aside from the ones mentioned below, I want to mention the new Token Scanning, which scans all public repos for commits containing tokens (like AWS API keys), that they’ve extended their vulnerability alerts to more languages, and that they now have a security API.
Possibly the biggest thing to come out of GitHub Universe is GitHub Actions. Unless you’re very new to this site1, I suspect that one look at the above link will tell you exactly why I’m excited about it. Basically it allows you to build a CI/CD pipeline directly in GitHub using Docker containers, using linked actions. If this sounds like other solutions I like, it’s probably because it is very similar.
Oh, there are some differences in the actual implementation and how you define the configuration. But in essence, it’s similar to what Wercker first created years ago2, and then Bitbucket introduced almost 2.5 years ago3. Just because they’re not first doesn’t make it any less useful however, and I signed up for the beta the moment I read about it. Unfortunately, I don’t have access yet so I’ll have to postpone describing those differences and how well it works until I’ve got hands-on experience.
GitHub Suggested Changes
Another feature that GitHub released4 is Suggested Changes. This is something that should help in speeding up the approval of pull requests. Where before a reviewer could only provide comments about the changes they wish to see, this actually grants them the ability to suggest changes that can immediately be applied from within the GitHub interface.
The way that this works is pretty smooth. As a reviewer you go through the code the same way you will always have, clicking the + sign on the line you wish to comment on. But now there is an extra button in the popup that allows you to add a suggested change. When you click on this button it will insert the line of code into your comment field as a Markdown code block that you can then change.
After you submit the “comment”, the creator of the pull request can then see it and easily apply it by going to the suggested change and clicking on “Apply suggestion”. It will even mark the reviewer as the author of the change in the commit that is created for this.
The biggest gain here is that instead of trying to describe the change they want, the reviewer can make the exact change. Thinking back at reviews I’ve done in the past, I can think of plenty of cases where this would have been useful. Ranging from typos that needed fixing to comments that I would have preferred to be written slightly different. In all honesty, there have been times where I’d let some of that slide because the time and effort of me writing the comment and the requester reading it, making the change, and finally updating the pull request wasn’t worth fixing a single character in a comment. But with this my need for perfection can finally be satisfied with minimum overhead!