Automating All the Code & Testing Things with GitHub Actions

Rate this content

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.

19 min
25 Oct, 2021


Sign in or register to post your comment.

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

Short description:

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

Short description:

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.

How do we actually automate all the things? If we're deploying anything even moderately complex, we have a bunch of things that we typically have to do in order to actually deploy our full stack. Those 10 commands or buttons that you have to run every time your Rails server and AWS infrastructure, well we can put that in a script. Scripts are probably the simplest form of automation. This helps us automate the manual tasks that we might have to take. So why not put them in a bash script? Or insert your favorite scripting language of choice, like Node, where you can even write it in JavaScript if that's your thing. The goal is to have a list of repeatable steps. And by using that one command with that script, you're able to do the exact same thing every single time. That way you never forget to leave anything out.

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

Short description:

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

Short description:

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.

If I wanted to post a message into Slack when a new pull request is made, I can use the post to Slack action, which I can configure in my project and set a note right to Slack. It's a helpful way to automate those little pieces of the development workflow. These last few were pretty simple examples, but it goes to show that with just a few lines, we can really do a lot of awesome things. So the cool thing, though, is we can take this up another level. We can create our own custom GitHub actions. Once you create a custom GitHub action, you really gain the flexibility to do whatever you want inside of that controlled environment. You have a few different options like running JavaScript with Node, or you can even run it with Docker, where you get the ability to do whatever you want. For instance, if I have a common task that includes a bunch of complicated things, I might not want to have to copy and paste that little snippet through every single repository. I can set up a Node script and run that script as part of my new action. That way, I only have to make that one reference inside of the action workflow between all my different projects.

5. AppleTools Eyes GitHub Action

Short description:

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

Short description:

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

Short description:

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

DevOps.js Conf 2022DevOps.js Conf 2022
33 min
Fine-tuning DevOps for People over Perfection
Demand for DevOps has increased in recent years as more organizations adopt cloud native technologies. Complexity has also increased and a "zero to hero" mentality leaves many people chasing perfection and FOMO. This session focusses instead on why maybe we shouldn't adopt a technology practice and how sometimes teams can achieve the same results prioritizing people over ops automation
controls. Let's look at amounts of and fine-tuning everything as code, pull requests, DevSecOps, Monitoring and more to prioritize developer well-being over optimization perfection. It can be a valid decision to deploy less and sleep better. And finally we'll examine how manual practice and discipline can be the key to superb products and experiences.
DevOps.js Conf 2022DevOps.js Conf 2022
27 min
Why is CI so Damn Slow?
We've all asked ourselves this while waiting an eternity for our CI job to finish. Slow CI not only wrecks developer productivity breaking our focus, it costs money in cloud computing fees, and wastes enormous amounts of electricity. Let’s take a dive into why this is the case and how we can solve it with better, faster tools.

DevOps.js Conf 2022DevOps.js Conf 2022
31 min
The Zen of Yarn
In the past years Yarn took a spot as one of the most common tools used to develop JavaScript projects, in no small part thanks to an opinionated set of guiding principles. But what are they? How do they apply to Yarn in practice? And just as important: how do they benefit you and your projects?
In this talk we won't dive into benchmarks or feature sets: instead, you'll learn how we approach Yarn’s development, how we explore new paths, how we keep our codebase healthy, and generally why we think Yarn will remain firmly set in our ecosystem for the years to come.

DevOps.js Conf 2021DevOps.js Conf 2021
33 min
How to Build CI/CD Pipelines for a Microservices Application
Microservices present many advantages for running modern software, but they also bring new challenges for both Deployment and Operational tasks. This session will discuss advantages and challenges of microservices and review the best practices of developing a microservice-based architecture.
We will discuss how container orchestration using Kubernetes or Red Hat OpenShift can help us and bring it all together with an example of Continuous Integration and Continuous Delivery (CI/CD) pipelines on top of OpenShift.

Workshops on related topic

DevOps.js Conf 2022DevOps.js Conf 2022
152 min
MERN Stack Application Deployment in Kubernetes
Deploying and managing JavaScript applications in Kubernetes can get tricky. Especially when a database also has to be part of the deployment. MongoDB Atlas has made developers' lives much easier, however, how do you take a SaaS product and integrate it with your existing Kubernetes cluster? This is where the MongoDB Atlas Operator comes into play. In this workshop, the attendees will learn about how to create a MERN (MongoDB, Express, React, Node.js) application locally, and how to deploy everything into a Kubernetes cluster with the Atlas Operator.

DevOps.js Conf 2022DevOps.js Conf 2022
13 min
Azure Static Web Apps (SWA) with Azure DevOps
Azure Static Web Apps were launched earlier in 2021, and out of the box, they could integrate your existing repository and deploy your Static Web App from Azure DevOps. This workshop demonstrates how to publish an Azure Static Web App with Azure DevOps.

DevOps.js Conf 2022DevOps.js Conf 2022
163 min
How to develop, build, and deploy Node.js microservices with Pulumi and Azure DevOps
The workshop gives a practical perspective of key principles needed to develop, build, and maintain a set of microservices in the Node.js stack. It covers specifics of creating isolated TypeScript services using the monorepo approach with lerna and yarn workspaces. The workshop includes an overview and a live exercise to create cloud environment with Pulumi framework and Azure services. The sessions fits the best developers who want to learn and practice build and deploy techniques using Azure stack and Pulumi for Node.js.

React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
Deploying React Native apps manually on a local machine can be complex. The differences between Android and iOS require developers to use specific tools and processes for each platform, including hardware requirements for iOS. Manual deployments also make it difficult to manage signing credentials, environment configurations, track releases, and to collaborate as a team.
Appflow is the cloud mobile DevOps platform built by Ionic. Using a service like Appflow to build React Native apps not only provides access to powerful computing resources, it can simplify the deployment process by providing a centralized environment for managing and distributing your app to multiple platforms. This can save time and resources, enable collaboration, as well as improve the overall reliability and scalability of an app.
In this workshop, you’ll deploy a React Native application for delivery to Android and iOS test devices using Appflow. You’ll also learn the steps for publishing to Google Play and Apple App Stores. No previous experience with deploying native applications is required, and you’ll come away with a deeper understanding of the mobile deployment process and best practices for how to use a cloud mobile DevOps platform to ship quickly at scale.