That’s a lot of things. For simplicity’s sake, here are five automations we think you should be running on your code:
1. Step up your security with CodeQL
Whether you’re working on an open source project or a widely used application, there’s one thing you never want to see: a climbing Hacker News post about how your software (or, software you rely on) has security vulnerabilities.
Combing through your code and advisory boards for security problems and zero-day vulnerabilities can be time consuming (but, also, not a bad thing to do if we’re being honest).
There’s a simpler way with CodeQL, GitHub’s semantic code analysis engine that runs security checks against a repository’s code to quickly identify any vulnerabilities. CodeQL finds security advisories across coding languages and packages, and then automatically displays them in your repository’s security tab.
It’s easy to do. And it can save you the headache of finding out about any security issues in your code on Hacker News or Twitter (which is always a win).
2. Run npm test in your workflows to push the latest and greatest
Most developers are using npm test (or similar commands) to test their code and for good reason: it’s a powerful yet simple tool that makes testing for any number of things simple.
Check out this example of something I’ve used recently in a repository I’m working on:
This means every time I run npm test in a GitHub Actions workflow, it will reference this script in my package.json file. It also automatically runs clean and node scripts tests and updates the jest snapshot to make sure I’m pushing the latest and greatest software all the time.
Here’s why this matters: if your npm tests are passing, you should have some confidence to push to production.
But like I said, npm test is a flexible, simple, and powerful tool that can do a lot depending on what scripts you put in your package.json file. Here are a few common things that I’ll add just to be safe:
3. Take a look at your build with automated visual tests
This might sound like a bit of a no-brainer, but being able to see your stuff live on a server is pretty useful.
Even just seeing if your buttons work correctly can be super helpful. Consider the age-old UI problem where a developer spends all their time perfecting the app functionality to eventually ship it without a login button (this has actually happened IRL).
Pro tip: Since Lighthouse offers CLI functionality, you can also run it directly in your GitHub Actions workflow from there.
Sanctioned by the Google Chrome team, this GitHub Actions workflow makes web testing simple—and, by building it into your CI pipeline, you can make sure you’re always delivering the best possible web experience every time you ship.
5. Automate your releases (and release notes) with GitHub Actions
As a developer, I know how great it feels after you’ve released a project. I also know how time consuming it can be to write the release notes, check the code, and actually release the thing you worked on.
Enter the latest version of GitHub Releases. Launched in 2021 in a general beta, the new version supports auto-generated release notes and automated releases (among a few other things).
Once you squash and merge a release request, manually run your Bump Version workflow.
Bump Version will create a new release by bumping the latest version using the npm version command; this will then push that new release and tag to your repository. Meanwhile, the tag triggers Create Release which makes a GitHub release, auto-generates the changelog release notes, and publishes to npm.
Simple. Don’t believe me? Check out the video below from the legend himself, Myles Borins, who helped build these features in GitHub:
The bottom line
When it comes to automations and automated tests, there are plenty of things you can do, but there are also plenty of things that most people aren’t doing. With a few simple additions to your repository, you can make sure your code is more secure, your applications run faster, and your releases go smoother, among other things.