Skip To Main Content

GitHub Actions for WordPress Theme Changes

github actions logo

GitHub Actions functionality has been around for years. Since I’m a web developer and need to work locally and deploy to a remote server, I want to use as few services as possible. I store my code in GitHub, so when I dove into GitHub’s automation offering, I had to use GitHub Actions for WordPress!

I am a big fan of Headless WordPress since the upsides are so great, but there are downsides. One of the downsides is you are basically developing two sites; one WordPress and one NextJS (or whatever your frontend is). There isn’t a lot of development on the WordPress side, but it’s not zero. I’ve automated the deployment process in order to speed things up for me. If you’re wondering what headless WordPress is, I’ve written about it.

Development Process

I create the code locally and run visual regression or user tests, but then I want to push my final product to the user. A few steps exist between creating the code and end users using it. I test it, format it, store it, etc. I can do most of that locally and on my machine, but to store it securely and allow others to contribute, I store my code in a GitHub remote repository. 

Deployment Process

Eventually, I need the code to reside on the production server. I have used other means in the past, and some are still acceptable, depending on the scale of the project. FTP, File Transfer Protocol, or even the secure version of SFTP, can quickly move files from one location to another.FTP connects my computer in my office to the remote server. This is an excellent option for file transfers, especially the SFTP option, which you should opt for. I will always set up an SFTP on my servers and connect my local machine as a backup. Sometimes, logging into a server is nice, viewing the file system in a Finder-like window, and manipulating files if needed. It’s a good backup. 

The problem with FTP is scalability—there are two issues with scaling this process. If more than one developer is touching the code, the latest person to move their files to the server wins. The second is FTP, which transfers the entire file whether or not there are changes, thus increasing the bandwidth used. I’m not necessarily concerned about small FTP transfers here and there, but I get frustrated at the longer transfer times it takes to move files. I’m generally not paying for bandwidth or if I am getting close to limits, but there are certain operations where that is a reality of development.  

Other services can move code to the correct location at the right time. I’ve used services like Beanstalk and Jenkins. These are excellent services, but they usually have a higher set-up price or monthly subscription. I’m trying to get the most value out of a service that I already pay for. Not only do I pay for GitHub, but I want to prevent switching applications as much as possible because working in multiple environments can lead to context switching. Instead, I want to reduce context switching to increase productivity. 

GitHub Actions for WordPress

The answer is GitHub Actions for several reasons. I already use it. Its vibrant Marketplace has plenty of starters, examples, and inspiration, and it’s relatively simple to get up and running. 

I chose to use a Rsync type of transfer with my workflow instead of a git checkout or an FTP-type file transfer. For those who don’t know or need a refresher, Rsync compares the same file in two locations, then looks for changes and only transfers those changes. Similar to how git works by only tracking the changes. Rsync is also faster transfer and secure by nature. Rsync can work over secure SSH connections, resume interrupted transfers, and offer flexible file compression. Again, I’m not moving huge files or directories that would take minutes or longer. Often, it’s one or two minuscule changes in one or two files, but rsync makes this almost instantaneous. The GitHub Action Runner takes longer to start itself than the actual file transfer. 

The Setup

You’ll need a few things to start, but I will concentrate on my actual .yml file. 

Prerequisites: 

  1. Local development environment with git enabled
  2. GitHub Remote repository: yes, it must be a GitHub
  3. A remote server with SSH access

My remote server is a bare-bones Linux installation from AWS. There’s nothing there. It’s an empty computer with no apps except the operating system. I won’t get into it much here, but Rsync is a service not part of an operating system, so you may need to install it on your remote server. Also, if you don’t have it yet, you’ll need to set up SSH access on a remote server. 

GitHub Configuration

Let’s configure your GitHub repository. Navigate to the Settings tab. Then, in the sidebar, there is a menu item for Secrets and Variables > Actions. You should have a screen on which you’ll add some repository secrets. You must add four secrets as a “key:value” pair. Understand that once you add the secret, you won’t be able to view it anymore. You can update it, though, but not view it. Add the following keys and values: 

EC2_SSH_KEY

HOST_DNS

TARGET_DIR

USERNAME

Now, when the GitHub Action needs to use those secrets, they’ll be accessible on the secrets.* object that is available to the runner.

Add files to your project with the exact name. Add a directory named .github. Inside that is a directory called Workflows. Then, inside that, a .yml file can be named anything, but for us, let’s call it github-actions-ec2.yml

Paste the following code into your .yml file. Remember that spacing and indentation matter in .yml files, so you may want to paste it into your text editor first and reformat there. Commit and push to your repository. 

 

name: Push-to-EC2
 
# Trigger deployment only on push to main branch
on:
  push:
    branches:
      - master
 
jobs:
  deploy:
    name: Deploy to EC2 on master branch push
    runs-on: ubuntu-latest
 
    steps:
      - name: Checkout the files
        uses: actions/checkout@v2
 
      - name: Deploy files via rsync
        uses: D3rHase/rsync-deploy-action@latest
        with:
          HOST: ${{ secrets.HOST_DNS }}
          PORT: 22
          USER: ${{ secrets.USERNAME }}
          PRIVATE_SSH_KEY: ${{ secrets.EC2_SSH_KEY }}
          REPOSITORY_PATH: '/*'
          SERVER_PATH: ${{ secrets.TARGET_DIR }}
 
      - name: Notify Deployment Success
        run: echo "Deployment to ${{ secrets.HOST_DNS }} completed successfully!"

Conclusion

In his blog post, the we went over the benefits of using GitHub Actions for WordPress development and deployment. I explained that GitHub Actions is a relatively simple and cost-effective way to automate the deployment process. You also recieved detailed instructions on how to set up GitHub Actions for WordPress, including how to configure repository secrets and create a .yml file. Overall, the blog post is a valuable resource for anyone looking to use GitHub Actions for WordPress development.