5 automations every developer should be running

As developers, we get a bad rap for not writing tests—or automations for that matter—as much as we should.

It’s not that we don’t do it (well, maybe some of us don’t). But it’s a fact that writing more code can be a little more fun than spending time writing tests and automations.

Here’s the good news: GitHub Actions offers thousands of pre-written, community-built tests and automations that range from code quality to code review to security to, well, testing. And all of these can be customized to fit your needs, or incorporated into a CI/CD pipeline with GitHub Actions.

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.

The best part? You can leverage a pre-built GitHub Action to run these security checks. That means it’s as simple as setting up a GitHub Actions workflow and applying it to pull requests and code merges to quickly scan for any known vulnerabilities.

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.

For the folks not writing JavaScript, npm test is a command that is configured via the package.json file that’s part of an application. Within this package.json file, you can add any number of scripts to test things ranging from accessibility to security.

Check out this example of something I’ve used recently in a repository I’m working on:

"scripts": {
"test": "npm run clean && node scripts/test.js --env=jsdom --updateSnapshot",
}

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:

• Test accessibility to make sure all HTML elements have aria (you can find my guide here).
• Confirm all links in the site work and don’t 404 (here’s a great GitHub Actions workflow to test this).
• Run unit tests on UI components to make sure buttons work (here’s a great guide from Playwright).

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).

Funny maybe, but also fear inducing (and, maybe even the definition of schadenfreude).

Cue automated visual testing, which is a way to automate the deployment of your code to a test environment where you can interact with what you’ve just built.

The best part: you can use a pre-built action in the GitHub Marketplace like Cypress (which is open source) and put it directly in your GitHub Actions workflows as part of your testing cycle.

This gives you a fast way to test anything with a headless browser to make sure everything looks like it’s supposed to—and, it also gives you real-time logs.

4. Use Lighthouse to make sure you’re not slowing your website down

First, a note: making Lighthouse checks a part of your CI or automated test is something not everyone does, but everyone should be doing.

Why? Sometimes, a development change to a website or web-based app will negatively impact your website performance. This has impacts for SEO, user experience, and more.

Lighthouse is an open source, lightweight tool that’s available in Chrome DevTools, as a Node module, or from your command line that tests website page quality for:

• Accessibility
• Performance
• Progressive web apps
• SEO
• And a number of other things

It’s also available in the GitHub Marketplace as an Actions workflow that you can build right into your CI pipeline to automatically check any coding changes for their impact to overall site performance.

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).

Here’s how to get started:

1. Add the pre-built workflow Create Release to your CI pipeline in GitHub Actions.
2. Add in the workflow Bump Version as a standalone GitHub Actions workflow.
3. 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.

Additional resources

• [Resource] How automation and CI/CD work on GitHub
• [Blog] 10 GitHub Actions resources to bookmark
• [Blog] 7 advanced workflow automation features with GitHub Actions

Written by

Brian Douglas

@bdougie