A collection of components for displaying Git information in your prompt
Automating build/deploy CI/CD with GitHub Actions
Last Updated
A version of this article appeared on viget.com
Projects hosted on GitHub can implement continuous integration (CI), continuous deployment (CD), and continuous delivery (the other CD) with GitHub Actions workflows. This works in public and private repos. (There are tiered limits for storage and time.)
In this article we will look at the basic structure of GitHub Actions workflows, and then build out support to test all branches and then deploy production builds to a remote server via FTP. No GitHub Actions background is necessary, but a basic understanding YAML will be helpful.
(Why deploy via FTP? In my case, I needed to deploy a static generated Nuxt app to production. Using a service like Netlify or Vercel was not an option, and I had FTP access to the server but not SSH access (I hope you aren’t in the same situation). But the FTP part of this is just a small detail; the final deploy workflow is flexible and can be adapted to your needs.)
Goal
The goal is to build every branch when it is pushed, and to deploy the trunk branch when it builds successfully.
To get there with GitHub Actions we’ll use two workflows: one which builds, and one which builds and then deploys. They will have these features:
- The “build” (continuous integration, for features) workflow runs when any branch other than the trunk is pushed
- The “build” workflow caches Node dependencies, a performance optimization that can speed up the build job.
- The “build and then deploy” (continuous integration and continuous deployment, for production) workflow runs when the trunk branch is pushed
- The “build and then deploy” workflow’s deploy job runs only if the build step passes. This prevents bugs from being deployed.
- The “build and then deploy” workflow’s build job calls the “build” workflow. This makes the setup easier to maintain— the build job is written once, and used everywhere.
- The “build and then deploy” workflow’s deploy job deploys an artifact produced by the build step.*
* In GitHub Actions, using an artifact from one job in another requires uploading the artifact to GitHub as a file. The file is available for download after the workflow completes (by default for 90 days). That means that even though supporting manual continuous delivery at an arbitrary time is not a goal of the solution we’ll build, we do get pretty close to it by continuously delivering the built artifact to the continuous deployment workflow; if continuous delivery separate from automated deployment is a goal of yours, this file will be useful: where I have “build” and “build and deploy” workflows and configure the file to live just long enough for automated deployment, use just a “build” workflow and configure it to live as long as your process requires.
Concept
Let’s look at annotated barebones workflows. These are missing build and deploy steps, but they illustrate the structure. Working examples come next.
Build workflow
- Runs when called from another workflow
- Runs when any branch other than
main
is pushed - Runs on Linux
- Caches Node dependencies
- If the build steps are successful, uploads a build artifact
Build and deploy workflow
- When
main
is pushed, runs the “build” workflow’s build job. This code reuse makes our setup easier to maintain - If the build job succeeds, runs deploy steps
Working example
Now let’s see it for real, building a Node app and deploying it via FTP. (If you aren’t uploading via FTP, your deploy step(s) will be different.)
Build steps have been added to the build
workflow. Deploy steps have been added to the build-deploy
workflow.
Try it out
Make sure Actions are enabled in your GitHub repo: repo > Settings tab > Actions > “Allow all actions” or “Allow select actions”. Adapt the workflows to your needs, then commit them in a non-trunk branch and push to GitHub. Go to your GitHub repo’s Actions tab to see the build
workflow running. Merge into your trunk branch, push, and go to the Actions tab to see the build-deploy
workflow running.
Bonus
Every GitHub Actions workflow has a status badge at <workflow file path>/badge.svg
. To show the world that production is healthy, modify this snippet and add it to your README.md:
References
GitHub Actions documentation
- GitHub Docs > GitHub Actions > Learn GitHub Actions > Reusing workflows
- GitHub Docs > GitHub Actions > Learn GitHub Actions > Workflow syntax >
jobs..needs
- GitHub Docs > GitHub Actions > Learn GitHub Actions > Workflow syntax >
jobs..runs-on
- GitHub Docs > GitHub Actions > Learn GitHub Actions > Workflow syntax >
jobs..steps
- GitHub Docs > GitHub Actions > Learn GitHub Actions > Workflow syntax >
jobs..uses
- GitHub Docs > GitHub Actions > Learn GitHub Actions > Workflow syntax >
on..
Actions used
- cache action
- checkout action
- download-artifact action
- sebastianpopp/ftp-action action
- setup-node action
- upload-artifact action
Updates
March 25, 2024: Use “same repository” syntax for calling the build workflow from the build-deploy workflow.
Articles You Might Enjoy
-
Git Prompt Kit: Configurable, Fast Git Status Components For Custom Zsh Themes
-
Writing zsh tab completions can be straightforward
How I add tab completion for the zsh command line
-
Highlight Code Block Lines In Eleventy with Shiki Twoslash
Eleventy Markdown code block line highlighting made simple