Automating Workflows with GitHub Actions

If you’re like most developers, you love being able to automate tedious tasks. Especially when automating these tedious tasks is a quick and pain-free process. That is why today I’ll be introducing you to the world of GitHub actions. For how amazing GitHub Actions are, I’m surprised it took me as long as it did to discover them. With just 16 lines of YAML code, I can automatically deploy changes made to the main branch of a repository directly to a server. What is great about these workflows, is not only can I push changes through FTP or SSH, I can also build and deploy docker images and NodeJS projects directly to a wide variety of services, including AWS, and DigitalOcean. At the risk of this sounding like a sales pitch, the way that they have the workflow process designed is brilliant. GitHub workflows are extremely powerful, and yet the interface for setting them up is extremely simple and user-friendly. Regardless of whether you’re a large company or an independent developer wanting to automate their workflows, GitHub Actions is definitely the way to go.

In this article, we are going to create our own repository from scratch, add some code, and then create the action that automatically uploads our changes to an FTP server. We’ll also look at doing the same through SSH. So without further ado, let’s get into it.

Creating a Repository for your Automated Deployments

To improve the ease of understanding the content in this article, we are going to start from scratch and create our own repository. If you already have a GitHub repository where your project’s code is kept up-to-date, then you can skip this step, or you can continue reading if you’re so inclined.

If you’ve never created a repository on GitHub before, you can click the little plus sign in the top right of the page and click “New Repository” or simply head on over to https://github.com/new if you’re already signed in to your account. Once we are on this page we can give our repository a name, set its access level to public or private, and specify some further options such as whether or not to include a README file, or if we’d like to include a .gitignore file to ignore certain files from being included in our commits.

After we’ve set up a new repository to our liking, there are a few different ways to proceed. If you already have an existing project on your local machine that you’d like to add to the repository, you will need to first initialize the root directory of your project as a git project.

git init

After we’ve initialized our repository, we can then specify the GitHub repository where we’ll push our changes to. In this example command, you’ll need to replace the URL with a URL to your own project. You can do this easily by going to the repository you’d like to grab the link for, clicking the green “Code” button, and then copying the link that appears in the popup. Make sure that the link ends with “.git”.

git remote add origin https://github.com/username/repository.git

After this, we can go ahead and add our entire project to the repository.

git add .
git commit -m “First Commit”

This will add all of the files in your current directory to the repository and then commit these changes. After we’ve done this, we can then push these changes to the remote repository on GitHub.

git push origin main

This will push the changes directly onto the main branch. This is the branch where your final code should reside. If you’re working on a website that is public-facing and attracting a lot of visitors, it is bad practice to utilize git in this fashion. It is a better idea to instead set up a separate branch for development, which pushes changes to a staging server that you can test the functionality on, before merging that branch with main and manually pushing the code to the production server. But for an independent developer who isn’t worried about issues with their code, this is perfectly acceptable. But it is a good idea to keep these best practices in the back of your mind if you intend on working as an employed developer.

Now that we have our code hosted on our remote GitHub repository, we can configure the GitHub Action to push these changes to a remote server.

Creating GitHub Actions

As I said at the beginning of this article, creating GitHub Actions is actually extremely easy to do, and requires no more than 16 lines of YAML. For those unfamiliar with YAML, it is what is known as a data serialization language. Similar to JSON, YAML is often used in configuration files by various services, since it is very easy to define parameters, and then subsequently read these parameters programmatically. Because of the lightweight nature of YAML in particular, it makes it especially desirable for services wanting to enable extended configuration for their users.

We aren’t going to dive too much into the syntax for YAML, as I feel that for anyone reading it, it should be pretty self-explanatory as to what it is doing. I will, however, explain what a couple of the lines in the YAML script are doing, since it might not immediately be apparent. So now, let us take a look at the script.

Deploying Changes via FTP

name: Deploy on Push
on: push
jobs:
  web-deploy:
    name: Deploy
    runs-on: ubuntu-latest
  
    steps:
  
      - name: Get Latest Code
      uses: actions/checkout@v2
      - name: Sync Files
      uses: SamKirkland/FTP-Deploy-Action@4.0.0
      with:
        server: 172.217.165.3
        username: pburkart@google.ca
        password: ${{ secrets.FTP_PASSWORD }}

So let us break this down line by line as to what we’re doing. The first line is pretty self-explanatory. It just specifies that this particular action has been given the name “Deploy on Push”. You will see this name listed under your workflows on the Actions page. The second line specifies when this particular action will run, and we set this to push. Meaning, whenever changes are committed to the repository's main branch, the following jobs will run. In the jobs section, we have one job, web-deploy, with the readable name “Deploy”. The runs-on line specifies what environment to run this action on. Currently, ubuntu-latest is Ubuntu 20.04. After this, we define the steps for the web-deploy job. The first step, “Get Latest Code”, checks out the latest commit to the repository so that it is accessible to your workflow.

The next step, “Sync Files”, uses Sam Kirkland’s “FTP-Deploy-Action” script to deploy the changes via FTP. After we specify which action we are using, we then specify its parameters using “with”. We first specify the IP address or domain name the FTP server is running on (which in this case I have set to a Google IP), and then we specify our credentials for logging into the FTP server. Looking at this section of the YAML script you may have noticed the final line looks a little odd, and that’s because it is, but it’s also another reason why I love GitHub Actions. Using GitHub Secrets, we can keep certain details private from anyone viewing the YAML script. To configure a secret for our FTP password, we’ll have to go to the settings page for our repository. Towards the bottom of the left-side navigation for this page, you will see the Secrets page. Under this page, we can easily create a repository secret and securely store our password.

Once you have configured the YAML file and the FTP Password, it is time to test it out. On your local machine, open up your project and make some changes. Once you’re satisfied with the changes you have made, open up Git bash (or your preferred method of using Git), commit the changes, and push them to the repository. Once you have pushed new changes to the repository's main branch, head over to the actions page. You should now see a new row with a yellow dot to the left, indicating that is queued. Once the action is in progress, the yellow dot will become animated, and once it is done, it will turn into a green checkmark. If for whatever reason it fails, you will see a red X. Clicking on this action will tell you why it failed. If the connection timed out, try again. Sometimes, especially when pushing multiple changes in short periods of time it will fail but will work when you retry. If it keeps failing to connect, ensure that the FTP details you have are correct by connecting to the FTP server with an FTP client.

Deploying Changes via SSH

Now that we’ve looked at deploying changes, let us take a look at deploying changes via SSH. The majority of the process is still the same, we just need to use a different action for actually deploying the changes.

name: Deploy on Push
on: push
jobs:
  web-deploy:
    name: Deploy
    runs-on: ubuntu-latest
    steps:
      - name: Get Latest Code
      uses: actions/checkout@v2
      - name: Sync Files
      uses: easingthemes/ssh-deploy@v2.1.5
      env:
        SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
        REMOTE_HOST: 172.217.165.3
        REMOTE_USER: pburkart

In this instance, we use an SSH private key to connect. I’m not going to cover how to go about creating this SSH key, but most web hosting providers allow you to easily create an SSH account and download the private key. We can create the secret for our SSH key in the same fashion we created the secret for our FTP password. We will simply need to paste the contents of the private key file into the box. One key difference between the scripts for SSH and FTP is that this script uses the env keyword to specify the data used by the script, whereas the FTP script uses “with”.

It’s as easy as that. We’ve now covered how to deploy changes automatically with both SSH and FTP. I hope you enjoyed reading this article. As always feedback is welcome. Have fun setting up your automated deployments!

Sick of feeling like you can’t get by without a tutorial? Check out my other article on Escaping Tutorial Purgatory as a Software Developer.

If you’re interested in being notified whenever I publish a new article, sign up for my newsletter on my website, paulburkart.ca.