GitHub Actions Day 6: Fail-Fast Matrix Workflows
December 6, 2019
If you're getting started setting up your first matrix workflow, then there's a caveat that you need to be aware of: by default, matrix workflows fail fast. That is to say: if one of the jobs in the matrix expansion fails, the rest of the jobs will be cancelled. This behavior is often very beneficial, but when you're creating a workflow from scratch, you may need to iterate a bit to get it working right the first time. And when jobs fail because there's a problem in the workflow setup -- and not in the code itself -- it can be helpful to turn off the fail-fast behavior as a debugging tool.
GitHub Actions Day 5: Building in Containers
December 5, 2019
Yesterday I talked about how to install tools and dependencies on the GitHub Actions virtual environments. But what if you need still more control? Or what if you don't want to run on Ubuntu at all? This is where containers shine. By creating a container that contains all the development tools that you need and your project's dependencies, you don't have to worry about managing those set up and installation steps at the beginning of your workflow run.
GitHub Actions Day 4: Installing Tools
December 4, 2019
I mentioned yesterday that GitHub Actions provides Linux, Windows and macOS virtual environments where you can run your workflows. And they've got a lot of tools installed on them. But - just by virtue of the wide variety of development tools out there - they can't have absolutely everything installed. Sometimes you'll need to install it yourself.
GitHub Actions Day 3: Cross-Platform Builds
December 3, 2019
One of the nice things about GitHub Actions is that it doesn't just support running builds on Linux hosts, or in containers. GitHub provides Linux virtual machines - of course - but they also provide virtual machines running Windows and macOS.
GitHub Actions Day 2: Matrix Workflows
December 2, 2019
One of the biggest advantages to having a CI/CD system is that it lets you build and test with multiple configurations efficiently. Building and testing on your machine before you push is certainly necessary, but it's rarely sufficient. After all, you probably only have one version of node installed. But building on a variety of platforms will give you confidence and insight that your changes work across the entire ecosystem that you support. Thankfully, matrix workflows in GitHub Actions can simplify running builds and tests on multiple configurations.
GitHub Actions Day 1: CI/CD Triggers
December 1, 2019
GitHub Actions is a unique system: it provides CI/CD build functionality - the ability to build and test pull requests and merges into your master branch - but it's more than just a build system. So you need to specify when workflows should run, with triggers. For CI/CD workflows, I like to use the push and pull\_request triggers, and scope it to the branches that I'm interested in.
GitHub Actions Advent Calendar
December 1, 2019
This December I'll be publishing an advent calendar of top tips for GitHub Actions. A new tip or trick every day! I'll keep this page updated as I go; I hope you enjoy!
Mirroring Git Repositories
July 22, 2019
One of the unique features about a DVCS - like Git - is that it gives you portability of your repository. As a result of this, it's very easy to move or copy a repostiory from one place to another; you can run git clone --mirror to get a clone of a remote repository with all the information, then take that and git push --mirror it to another location. The problem with that, though, is that hosting providers have private, read-only branches. That means that if you just naively git pull --mirror from one GitHub repository, and then try to git push --mirror to another repository, then your push will show a lot of errors about how you can't push those private, read-only references that are custom to GitHub. But here's a script that can help. I call it mirror.sh...
Advent Day 24: The Reflog
December 24, 2018
There are precious few things in Git that save my bacon more often than the reflog. And knowing it's there encourages me to craft my commits, often rebasing them, into a manner that's easy to read for my collaborators. But it's not always easy to craft an easy-to-read pull request. It often means taking their feedback and going back to fix up prior commits, rewriting and rebasing. But what happens if you get this wrong? If you've rewritten a bunch of changes, and you made some errors, how do you get back to the ones that you rewrote? The reflog.
Advent Day 23: Removing Large Binaries with LFS
December 23, 2018
Earlier this month I talked about Git Large File Storage (LFS) and how you can use it to avoid checking in large files. It will keep those files in a separate area, parallel to (but not actually part of) your git repository, where they have a different storage contract that's efficient for large files. But Git LFS needs to be set up before you add the binaries to your repository - once they've been checked in, they're in history. But what if you've already added binaries to your repository? How do you get them out?