Code tasks like linting and testing are critical pieces of a developer’s workflow that help keep us sane like preventing syntax or style issues and hardening our core business logic. We’ll talk about how we can use GitHub Actions to automate these tasks and help keep our projects running smoothly.
Automating All the Code & Testing Things with GitHub Actions
AI Generated Video Summary
We will learn how to automate code and testing with GitHub Actions, including linting, formatting, testing, and deployments. Automating deployments with scripts and Git hooks can help avoid mistakes. Popular CI-CD frameworks like Jenkins offer powerful orchestration but can be challenging to work with. GitHub Actions are flexible and approachable, allowing for environment setup, testing, deployment, and custom actions. A custom AppleTools Eyes GitHub action simplifies visual testing. Other examples include automating content reminders for sharing old content and tutorials.
1. Introduction to Code Automation and Testing
We're going to learn how to automate code and testing with GitHub Actions. Linting helps pinpoint syntax errors and ensures consistent code style. Formatting tools like Prettier fix code issues automatically. Testing is essential for preventing errors and ensuring functionality. Regularly running tests is crucial. Deployments are necessary to make your application accessible to users.
Hey, everyone. We're going to learn how we can automate all the things, all the code and testing things with GitHub Actions. So who am I? I'm Colby Fayok. I'm the one hugging BB8 and Kylo Ren over there. I work with the dev community as a developer advocate for Applitools. You can find me pretty much anywhere on the web by just googling my name as I'm the only one in the world.
So we're going to just jump right into it. As developers, we have a bunch of tasks that we have to deal with day to day. And particularly, we're going to talk about code tasks. So let's see what some of those might look like.
Well, first there's linting. Linting basically tells you if you write sloppy code. But on a serious note, it can be really helpful for actually pinpointing syntax errors. It's also generally helpful for making sure that your code looks like the same person wrote it, which makes your code easy to read and also work through as a team. The problem is, unless you're running some kind of modern framework with it out of the box, you have to remember to actually run it.
Formatting is basically linting, but it will fix all those issues for you. Your linter like eslint might even do it itself. But with formatting, you have tools like Prettier, where they will format the code and they'll even include an opinionated configuration. Linting and formatting come with a lot of super practical benefits. You also benefit from not having to actually spend time in code reviews where you're going to argue over syntax preferences. You can let the robots be the bad cop and actually do it for you. There's less that you have to think about and less that you actually have to stress about. But again, your worst enemy here is remembering to actually run it.
Even more critical to a developer's workflow is testing, and while formatting and linting help prevent errors, it's more so static analysis, and it helps you find the syntax errors. But it's not doing a lot to actually test the functionality. Tests will help to make sure that you're not breaking things and end up losing money when your online store is down. The tests aren't just for your QA engineer to run every once in a while. You need to actually run these tests regularly, otherwise they're not really doing their job.
And finally, the last thing that we'll talk about is deployments. And ultimately, you want your application to actually go somewhere so that people can actually use it.
2. Automating Deployments with Scripts and Git Hooks
Deployments can be complex and prone to human error. Automating the deployment process can help avoid mistakes. Scripts and Git hooks are useful for automation. Git hooks can trigger actions at different points in the Git process. For example, a precommit hook can automate formatting. Lint staged allows for targeted changes to be impacted by the precommit hook. However, running tests as a precommit hook can be inconvenient for developers.
Deployments can be painful, especially for large complex infrastructures where there's a lot of moving pieces. On top of this, you have to remember to deploy all those pieces and missing one step can take the site down in a bad way, not just because you're deploying a new version and have a little time between different migrations. A theme through all these tasks, though, are they're all important in one way or another. They help us focus on the real challenges of the work, not the drama in the code review or stumbling through another code deploy or, but another theme, they all require humans to do them.
That means they're prone to human error. And whether it's simply for getting to run something or forgetting to include a particular step, even for getting to do it in the right order, what can we do to actually avoid those human mistakes? Well we can automate it, of course. So let's learn how to automate all the things.
But scripts also ultimately rely on something to trigger that. If it's still a human, you might forget to run that script in the first place. Or if somebody's filling in for a day, maybe they don't even know that you have a script to run this setup. A feature that comes baked in to Git itself is Git hooks. With Git hooks, you can trigger something at different points of the Git process. For instance, you can setup a commit hook, where any time you actually run a commit, your hook will run, automating some part of your process, where a good example for that is formatting. Any time someone commits, you can setup Prettier, or any other formatter, to run before the commit actually applies. With your existing scripts to run linting and formatting, this is called a precommit, where, with tools like Husky, you can hook in and manage all those Git hooks. We're also applying lint staged here, which allows us to get the path of all those changes that we actually get in the stage for Git, where that way, when we run our precommit hook, we're not affecting the entire repository tree, we're only impacting the files that actually changed. But once that script finishes, those changes are added onto the Git stage before that commit is actually applied. So when the actual commit happens, all Git knows is that the code is pretty and formatted. All the developer knows is they got their job done, and when the code is actually pushed up to GitHub, it looks like that one person wrote it. But not everything makes sense inside of a Git hook. You don't want to run your tests as a precommit hook, for example, where that's going to be a huge pain for developers. Imagine you're working on a project with a huge test suite and in order to actually commit, you have to run that entire suite.
3. Automating CI-CD Processes with Frameworks
CI-CD processes automate code deployment and integration. Popular frameworks like Jenkins, Bamboo, CircleCI, and Travis CI offer various levels of scripting and configuration. Setting up CI-CD allows for powerful orchestration of infrastructure, from deploying lambdas to creating networking rules. However, some frameworks, like Jenkins, can be challenging to work with, especially for front-end engineers. They often require server maintenance and long build times. A more desirable solution is a plug-and-play option.
Nope. Nope. Nope. Nope. So we can take that up another level by running CI-CD processes. CI is continuous integration. CD is continuous deployment, or sometimes continuous delivery.
While some teams still require that to be kicked off manually, that kind of defeats the purpose, where the goal of CI-CD is to be automated within your code processes. So for instance, if you want to push your changes to the main branch, that triggers a certain set of functionality. And if you push to a feature branch, maybe that triggers a different set of functionality.
Some popular frameworks for running these processes are Jenkins, Bamboo, CircleCI, and Travis CI. And depending on the framework, setup might look a little bit different. Most of them depend on some kind of configuration. But you can have various levels of scripting included right inside, where here we have a simple example. And I personally still have nightmares from actually working with Jenkins, where I'm primarily a front-end engineer. But the DevOps team swore by it. I think it's mostly because of the flexibility, though. Not necessarily the ease of it.
But setting up CI-CD can be super powerful. You can have large, complex orchestration of your entire infrastructure. Need to deploy some lambdas or dump a static site into storage? Add a script to your CI-CD processes. Need to spin up a VPC with strict networking rules? Well maybe Jenkins can do that for you. Because you're really leveraging scripting and automation of that scripting, you should really be able to accomplish anything that you want. But like I mentioned before, I'm a front-end engineer and I struggled with Jenkins. I didn't have great documentation to look at. At least at the time. And waiting for builds to finish took forever. For a lot of those frameworks, you have to also maintain servers. And did I mention that I'm a front-end engineer? I can spin up a node server, but I don't really want to deal with servers. Servers are so last decade, am I right? Kidding aside, I want something that I can easily plug and play.
4. GitHub Actions and Custom Actions
GitHub Actions are flexible and approachable. They allow you to set up the environment, run tests, deploy code, and automate tasks. You can even create custom actions for more control. With just a few lines, you can do a lot of awesome things.
Something that's close to the rest of my code that I don't have to fight with. And after all that build-up, that's where GitHub Actions comes in. GitHub Actions are still technically CICD, but in practice, they actually feel so much more approachable. The best part is they can be just as flexible. With Actions, you can start off by setting up the environment you want to run inside of the workflow file. You can add whatever commands you want, when you want to run them, and you're off.
For instance, if I wanted to simply run some tests, I can set up a test file to run in Ubuntu, or a variety of other options. Then I can check out that code where I'll be running the commands inside of a working directory. To set up Node, I can add another Action where I specify the version. I can even make this run on a few different versions of Node if I wanted to, within the same workflow. And then finally, I install the dependencies and I run the tests. This alone will make sure that I have tests that run every single time a change is pushed or if a pull request is created in this particular instance.
As they run, they show up right in line with the rest of that pull request, letting you know by just a quick look if your proposed changes actually breaks things or not. This helps to get a great feedback loop for developers when, if something isn't working, they'll get that feedback quickly. I could also use GitHub actions to deploy code. Once I install my project dependencies, I can build that project. Then configure my AWS credentials as secrets and I can then sync those artifacts up to AWS to deploy. The AWS CLI is actually available by default, which makes this really simple to do inside of actions. And this includes any kind of commands with the AWS CLI. And I can even use actions from the GitHub marketplace.
5. AppleTools Eyes GitHub Action
I created an AppleTools Eyes GitHub action that simplifies visual testing. With just a snippet of code and your API key, you can easily run tests on your website or app.
That's exactly what I did with my AppleTools Eyes GitHub action. And just really quickly to add some context, Appletools is a visual testing platform where every time you run a test, Eyes takes a screenshot of your website or your mobile app and it compares those images with AI. To do that, Appletools has a ton of SDKs, whether it's Cyprus, like you see here, or Selenium Java, or really any popular testing framework that allows you to drop the SDK into those existing tests. And this is already pretty easy to do, but I wanted to make it even easier. I wanted a solution where somebody who might not even have testing set up inside their project could easily drop this in and get visual testing, which is where we come back to Appletools Eyes GitHub action. And hence, this action just takes one snippet where you have to plug in your API key, which is required anytime you want to run a test to Appletools to make sure it actually sends it up to your account. And that way then you provide the URL for what you actually want to test.
6. Automating Visual Testing with AppleTools.eyes
The process starts by crawling the URL provided, either by clicking around the site or using a custom sitemap. The Sitemap Generator package is used for crawling and collecting site details. Cypress is then run inside a node script, allowing for the collection of results and the ability to provide a better developer experience. The tests are run dynamically based on the URLs, and the results can be commented on the pull request. The AppleTools.eyes action can be integrated into an existing Netlify workflow, simplifying the visual testing process for multiple projects.
Once that action actually starts off, it kicks off a process where we'll first crawl that URL that you pass in. It does this kind of similarly to what you would expect from Google when it does it with robots for searching with SEO, where it clicks around the site, tracks what links are available on your site, and it puts it together inside of a list. Or if you already have a custom sitemap, you can pass that in as the URL instead.
But to crawl, I use a package called Sitemap Generator, where I can run a simple node command and I can have that all inside of a list of URLs. Once I have collected all the site details and the configurations though, I can run Cypress right inside of that node script, including those URLs from the sitemap as an array that I pass in right into Cypress, which allows me to collect all of my results that I can use for later, such as failing the action if the tests actually fail or generally working with the results so I can provide a better developer experience inside of the GitHub repository.
But finally, Cypress runs those tests as it normally would, giving me my test runner and my results for the eyes check. The only difference being that this time, it's looping through all those pages to check for the sitemap, so it's running all those different tests dynamically based on the URLs. But that gives me my test runner and my results for that eyes check. With those results, I can actually comment right onto the pull request, whether they passed, failed, or if they're just unresolved, giving the maintainer of the project an easy way to know if the code actually introduced a bug or at a minimum introduced a breaking change. I even figured out a solution where we can plug this into an existing Netlify workflow. If you're not familiar with Netlify, they'll automatically deploy your static application all the way up from GitHub. And this happens any time that you actually push a change into your GitHub repository default branch. I was able to find an action where it waited for that deploy, and it actually stored that URL as output from that action workflow. I was able to take that and pass it right into my AppleTools.eyes action, which it did its thing, it went through and it crawled the site and it performed that visual test. But the entire project is ultimately a script that I need to run. Where running it between a few different projects is just a few input parameters of a difference. Instead of having to make sure that my testing framework is set up inside of every project, along with installing the SDK and actually writing all my tests, this makes it really easy to add AppleTools.eyes visual testing to any project with just these few lines.
7. GitHub Actions and Content Reminder Template
Let's explore other examples of GitHub actions, such as the content reminder template. This template helps content creators and educators remember to share old content and tutorials. It runs as a Node script on a cron schedule, sending email reminders to share random entries from RSS feeds.
So let's also check out a few other examples of GitHub actions that are out in the wild. I also created a GitHub action template called content reminder. The one thing that I struggle with as a content creator and educator is simply remembering to share some of my old content and tutorials. So I put on my developer hat and I tried to do something about it. I built content reminder as a GitHub action, where it's simply a Node script. But what happens is I run it on a cron so that it actually triggers two times every day. With Actions, not only can you run on GitHub events, you can run on the same old cron syntax that you're used to scheduling other runs. But once it does run, I run a Node script, where I look through a few RSS feeds of my content, I find a random entry, and I send myself an email with that content pushing me to share it out to the world.