In this episode, we are talking all about GitHub Actions. What are they, and why should you consider learning more about them? Also, Allen terminates the terminators, Outlaw remembers the good ol' days, and Joe tries his hand at sales.
See the full show notes at https://www.codingblocks.net/episode218
News
- Thanks for the reviews! iTunes: nononeveragain, JoeRecursionjoe, Viv-or-vyv, theoriginalniklas
- Leave us a review if you have a chance! (/reviews)
- Allen did some work on his computer:
- DeepCool LT720 Liquid Cooler (amazon)
- Noctua Dual-Tower CPU Cooler (amazon)
What are GitHub Actions?
- GitHub Actions is a CI/CD platform launched in 2018 that lets you define and automate workflows
- It's well integrated into Github.com and fits nicely with git paradigms - repository, branches, tags, pull requests, hashes, immutability (episode 195)
- The workflows can run on GitHub-hosted virtual machines, or on your own servers
- GitHub Actions are free for standard Github runners in public repositories and self-hosted runners, private repositories get a certain amount of "free" minutes and any overages are controlled by your spending limits
- 2000 minutes and 500MB for free, 3000 minutes and 1Gb for Pro, etc (docs.github.com)
- Examples of things you can do
- Automate builds and releases whenever a branch is changed
- Run tests or linters automatically on pull requests
- Automatically create or assign Issues, or labels to issues
- Publish changes to your gh-pages, wiki, releases,
- Check out the "Actions" tab on any github repository to check if a repository has anything setup (github.com)
- The "Actions" in GitHub Actions refers to the most atomic action that takes place - and we'll get there, but let us start from the top
Workflows
- Workflow is the highest level concept, you see any workflows that a repository has set up (learn.microsoft.com)
- A workflow is triggered by an event: push, pull request, issue being opened, manual action, api call, scheduled event, etc (learn.microsoft.com)
- TypeScript examples:
- CI - Runs linting, checking, builds, and publishes changes for all supported versions of Node on pull request or push to main or release-* branches
- Close Issues - Looks for stale issues and closes them with a message (using gh!)
- Code Scanning - Runs CodeQL checks on pull request, push, and on a weekly schedule
- Publish Nightly - Publishes the last set of successful builds every night
- Workflows can call other workflows in your repository, or in a repository you have access to
- Special note about calling other workflows - when embedding other workflows you can specify a specific version with either a tag or a commit # to make sure you're running exactly what you expect
- In the UI you'll see a filterable history of workflow runs on the right
- The workflow is associated with a yaml file located in ./github/workflows
- Clicking on a workflow in the left will show you a history of that workflow and a link to that file (cli.github.com)
Jobs
- Workflows are made up of jobs, which are associated with a "runner" (machine) (cli.github.com)
- Jobs are mainly just a container for "Steps" which are up next, but the important bit is that they are associated with a machine (virtual or you can provide your own either via network or container)
- Jobs can also be dependent on other jobs in the workflow - Github will figure out how to run things in the required order and parallelize anything it can
- You're minutes are counted by machine time, so if you have 2 jobs that run in parallel that each take 5 minutes…you're getting "charged" for 10 minutes
Steps
- Jobs are a group of steps that are executed in order on the same runner
- Data can easily be shared between steps by echoing output, setting environment variables or mutating files
- Each step runs an action
Actions GitHub Enterprise Onboarding Guide - GitHub Resources
- An action is a custom application written for the GitHub Actions platform
- GitHub provides a lot of actions and other 3p (verified or not) providers do as well in the "Marketplace", you can use other people's actions (as long as they don't delete it!), and you can write your own
- Marketplace Examples (github.com)
- Github Checkout - provides options for things like repository, fetch-depth, lfs (github.com)
- Setup .NET Core SDK - Sets up a .NET CLI environment for doing dotnet builds (github.com)
- Upload Artifact - Uploads data for sharing between jobs (90-day retention by default) (github.com)
- Docker Build Push - Has support for building a Docker container and pushing it to a repository (Note: ghrc is a valid repository and even free tiers have some free storage) (github.com)
- Custom Examples
- "run" command lets you run shell commands (docker builds, curl, echo, etc)
- Totally Custom (docs.github.com)
Other things to mention
- We glossed over a lot of the details about how things work - such as various contexts where data is available and how it's shared, how inputs and outputs are handled…just know that it's there! (docs.github.com)
- You grant job permissions, default is content-read-only but you must give fine-grained permissions to the jobs you run - write content, gh-pages, repository, issues, packages, etc
- There is a section under settings for setting secrets (unretrievable and masked in output) and variables for your jobs. You have to explicitly share secrets with other jobs you call
- There is support for "expressions" which are common programming constructions such as conditionals and string helper functions you can run to save you some scripting (docs.github.com)
Verdict
- Pros:
- GitHub Actions is amazing because it's built around git!
- Great features comparable (or much better) than other CI/CD providers
- Great integration with a popular tool you might already be using (docs.github.com)
- Works well w/ the concepts of Git By default, workflows cannot use actions from GitHub.com and GitHub Marketplace. You can restrict your developers to using actions that are stored on your GitHub Enterprise Server instance, which includes most official GitHub-authored actions, as well as any actions your developers create. Alternatively, to allow your developers to benefit from the full ecosystem of actions built by industry leaders and the open-source community, you can configure access to other actions from GitHub.com.
- Great free tier
- Great documentation https://docs.github.com/en/actions/using-containerized-services/creating-postgresql-service-containers
- Hosted/Enterprise version
- Cons:
- Working via commits can get ugly…make your changes in a branch and rebase when you're done!
Next Steps
- If you are interested in getting started with DevOps, or just learning a bit more about it, then this is a great way to go! It's a great investment in your skillset as a developer in any case.
- Examples:
- Build your project on every pull request or push to trunk
- Run your tests, output the results from a test coverage tool
- Run a linter or static analysis tool
- Post to X, Update LinkedIn whenever you create a new release
- Auto-tag issues that you haven't triaged yet
Resources We Like
Tip of the Week
- There is a GitHub Actions plugin for VSCode that provides a similar UI to the website. This is much easier than trying to make all your changes in Github.com or bouncing between VSCode and the website to see how your changes worked. It also offers some integrated documentation and code completion! It's definitely my preferred way of working with actions. (marketplace.visualstudio.com)
- Did you know that you can cancel terminating a terminating persistent volume in Kubernetes? Hopefully you never need to, but you can do it! (github.com)
- How are the Framework Wars going? Check out Google trends for one point of view. (trends.google.com)
- Rebasing is great, don't be afraid of it! A nice way to get started is to rebase while you are pulling to keep your commits on top.
git pull origin main --rebase=i - There's a Dockerfile Linter written in Haskell that will help you keep your Docker files in great shape. (docker.com)
