GitHub Actions - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. More than ten thousand ready made building blocks are sitting inside GitHub right now. They're called actions, and they plug into a tool called GitHub actions that runs your work for you. Whenever something happens in your project. Most people think automation like this needs servers and a DevOps team, but it comes down to one small text file. This is the M365 FM podcast where we explore the people, ideas and technologies shaping the future of work. And today we're breaking GitHub actions down in plain words for complete beginners. By the end, you'll be able to read a workflow file and say out loud what it does, what GitHub actions really is. Let's start with the plain definition, because the name does a lot of the intimidating work on its own.

0:41 GitHub Actions is an automation service that lives inside GitHub. Its job is to run tasks for you when something changes in your project, and at its core, that's all it really is. GitHub calls it a platform for continuous integration and continuous delivery, which sounds heavier than it needs to. Continuous integration is the habit of testing your work every time you change it. Rather than saving all of the testing up for the very end. Continuous delivery is what happens after those tests pass. When the finished thing gets sent out to wherever it needs to go. Put the two together and you get a simple promise your project can check itself and ship itself instead of waiting on a person to remember a repository. If that word is new to you, is just your projects folder on GitHub. Every time you save a change to that folder, you create what developers call a push.

1:22 A push is one of those moments where automation can step in. Before tools like this existed, somebody had to remember to run the tests. Otherwise, a separate build machine sat in a corner and waited for instructions. GitHub actions turns that into written instructions that a computer follows on its own every single time, without anyone standing over it. That matters for your bottom line, because manual steps are where mistakes hide. A person forgets to run the tests on a Friday afternoon, a broken change slips through, and the whole team spends Monday fixing production. When the instructions live in a file, instead of a person's memory, they don't get tired. They don't skip a step and they don't forget. The part that surprises people is how much of that work is already written for you, and we'll get to that soon. The first time you write one of these files, it's usually a small mess. That's fine because you can watch every step and fix it in place where the instructions live.

2:07 Now we get to the practical part because this is the piece you can actually see that set of instructions is called a workflow, and the workflow is a plain text file. It isn't hidden in a settings screen and it isn't locked behind an admin portal. It sits in your repository inside a folder called GitHub, and inside that folder called workflows. The folder name matters more than you'd expect because GitHub only looks there. Save your workflow anywhere else in GitHub will never find it. So nothing runs and nothing tells you why. The file itself can be named almost anything you like, as long as it ends in dot ml or dot ml. Those are two spellings of the same file. Type. Inside the file, you write a short list of instructions in a format called Yaml. Yaml cares about spacing and indentation, but the idea underneath it is friendly.

2:47 It reads from top to bottom like a recipe. One line gives the workflow a name so you can recognize it later in a list. Another line lists the events that should set it off. Then comes the real work in a section called jobs, where you spell out what should happen and which kind of computer should do it. Once a run is finished, you can watch the whole thing on the actions tab, where each job and each step shows its own log. That's how you find out why something failed. And it's a calm way to debug a process you never had to babysit. If you've ever built an automation in Power Automate, this will feel familiar. You pick a trigger, you add the actions that follow, and the whole thing runs without you. GitHub actions works on the same idea, except the recipe lives as text inside your project instead of a canvas in a browser. That difference sounds small, but it means the instructions can be reviewed, copied, and tracked like any other file, and you'll see why that matters later.

3:32 What wakes it up? Events. Every workflow needs a starting signal, and in GitHub actions, that signal is called an event. You list your events under a line called on, and when one of them happens, GitHub reads your file and gets to work. The most common event is the push which fires when you save changes to a branch. Next comes the pull request, which fires when somebody proposes a change and asks for it to be reviewed and merged. Those two cover most day to day work, but they're far from the whole list. A schedule can set it off using the same kind of timing rules that older scheduling tools have used for years. You can also start one manually with a button in the GitHub interface, and give that button a few options to choose from. Beyond that, it can fire when somebody opens an issue, comments on a pull request, creates a release, or edits a wiki page that changes the part.

4:14 People underestimate plenty of teams start out using this tool for tests and end up using it to label issues. Welcome new contributors, and post a reminder every Monday morning. The event is just a doorbell, and once you know how to wire it up, you can attach almost anything to the sound of it. One rule is worth remembering because it trips people up early. The workflow file has to exist on the branch or commit where the event happens. Some events only fire if the file also lives on your default branch. So if a workflow seems dead, that's the first place to look. Jobs, steps and runners. Once a workflow starts, it needs to know what to do. And that's where jobs come in. A job is one to do item, a bundle of work that runs on a single machine from start to finish. Jobs run in parallel by default, which means two jobs with no relationship to each other will run at the same time.

4:58 If one job genuinely depends on another, you say so, and the second one waits its turn. Inside a job, you write steps and steps run in order one after another, because every step runs on the same machine. The steps can share what they build. A first step might install your tools, a second might build the project, and a third might run the tests against what the second step just produced. That order matters, and GitHub stops the job. The moment a step fails, which is exactly what you want. When a test breaks, you choose the machine with a line called Runs On. So a job written for Linux and another written for windows can both live inside the same file. That keeps one workflow useful across a whole team. Even when everyone works on a different machine at home. There's one more trick here called a matrix, and it saves an enormous amount of typing.

5:40 A matrix lets you take a single job and run it several times with different settings. One definition can cover three operating systems or four language versions without you copying anything. It's a small feature that turns a messy file into a tidy one. Now we reach the word that makes beginner's eyes glaze over, and that word is runner. A runner is the computer that actually does the work. GitHub gives you machines running ubuntu, Linux, Windows, and Mac OS, and every single run starts on a fresh machine that was just created for that job. When the job finishes, that machine is thrown away. So nothing lingers behind and nothing leaks between runs. Each runner handles one job at a time, which is why two jobs on two runners can run side by side. The machine sizes are modest but real. A standard Linux runner for a public project has about four processors, sixteen gigabytes of memory, and fourteen gigabytes of disk.

6:25 That's plenty for most everyday builds. There's also a tiny single processor option built for light chores that comes with a fifteen minute limit, so it suits small tasks rather than heavy builds. If four processors aren't enough, larger runners exist with more memory, more disk, and options like a fixed address or graphics card. You don't have to use GitHub's machines at all either. If you need a particular operating system or a piece of hardware GitHub doesn't offer, you can attach your own computer as a self-hosted runner. That trade is simple to describe and easy to underestimate. Hosted runners mean nothing to maintain and nothing to patch. Self-hosted runners mean you own the machine and everything that goes wrong with it, and that bill arrives in engineer hours rather than dollars. The marketplace and reusable workflows. Here's the part that makes GitHub actions feel less like homework.

7:08 You rarely write all of those steps yourself, because an action is a pre-built block of code that does one job for you. Pulling your project's code onto the runner, setting up the right version of a programming language, logging into a cloud provider. Each of those is already somebody else's tested code. You drop a single line into your workflow and the work is handled for you. That's why most beginner workflows are short, often fewer than twenty lines, because the heavy lifting belongs to somebody else. Those blocks live in the GitHub marketplace, which passed ten thousand published actions back in twenty twenty one. Every action in the marketplace is open sourced, so you can read exactly what it does before you trust it. You can fork it and change it if it doesn't quite fit. GitHub also marks some actions with a verified creator badge, which tells you the publisher is a partner organization.

7:49 GitHub has checked. There's an honest caveat here, and it matters for your bottom line. A marketplace action is somebody else's code running inside your workflow with access to whatever you hand it. The badge and the open source license are the reasons to trust one, and a random action from an unknown account deserves a closer look before it touches your project. The second reuse trick solves a different problem. Suppose twenty repositories all need the same build and test routine. Copying the same file into twenty places works right up until you need to change one line, and then you're editing twenty files and hoping you didn't miss one. A reusable workflow lets you write that routine once in one place and call it from anywhere. You mark it with a setting called workflow call and other workflows. Call it by name passing in the settings and the passwords it needs.

8:31 You can even stack them up to ten levels deep. The simplest way to hold these two ideas apart is this. An action is one tool in your toolbox. A reusable workflow is the whole recipe, and it can be handed to any kitchen that needs to cook the same meal. Secrets keeping passwords out of the code. All of this runs without anyone watching. And that raises a fair question, because sooner or later, a workflow needs a password, an API key, or an access token. those values never belong in the workflow file, and that part isn't optional. They live somewhere else in a feature called secrets. GitHub lets you keep secrets at three levels depending on how widely they should be shared. Repository secrets belong to one project. Organization secrets can be shared across many projects with rules about which repositories are allowed to use them.

9:13 Environment secrets belong to a specific deployment target, like staging or production, and that's the level where you'd put the credentials for a live system. Secrets are encrypted before they even reach GitHub, and they stay hidden once they arrive. A workflow can only read a secret if you explicitly hand it over by name, which means a stray action can't help itself to every credential you own. GitHub also hides secret values in the logs, though the documentation is honest that this hiding isn't guaranteed because a value can be rearranged before it gets printed. Environment secrets can go a step further and require a human to approve a job before the secret even becomes available. One more detail separates a careful setup from a sloppy one. Secrets are meant for values you can't share, like passwords and access tokens. If a value is just a setting, like a website address or a version number.

9:56 It belongs in plain text where anyone reading the file can see what's going on. Mixing the two up makes a workflow harder to understand and harder to fix. The habit to build is easy to say and easy to skip. Give each secret the smallest set of permissions it needs and never paste a credential straight into a workflow file. Think of it as a locked box that you hand over by name, rather than a key taped to the front door. What people actually automate in the real world. This tool shows up first as a test runner. Every time somebody proposes a change, the workflow checks out the code, installs the tools, and runs the test suite. If something breaks, the person sees it within minutes before a human reviewer spends an hour on a broken change, that single habit catches an enormous number of mistakes, and it's the reason most teams turn this tool on in the first place.

10:38 Shipping is the next big use. When the tests pass and a release is created, the same tooling can build the finished package and send it out to wherever it lives. That might be an app store, a web server, or a package registry. What used to be a nervous manual checklist becomes a repeatable sequence that runs the same way every single time. If you've ever followed a written procedure at work and hoped you didn't miss a step, you already understand the appeal. Then there are the jobs that have nothing to do with code at all. A workflow can label a new issue automatically welcome a first time contributor with a comment or post a reminder on a schedule that changes why the tool shows up in so many places. And it's the same pattern you'd recognize from Power Automate. Something happens and something else follows without a person clicking anything.

11:18 It also helps to know that you're not learning a niche tool. In JetBrains twenty twenty five survey of eight hundred and five people working with these tools, GitHub actions was the most used option for personal projects, picked by sixty two percent of respondents and forty one percent said their organization uses it. At the same time, thirty two percent of organizations run two of these tools side by side, which tells you the skill travels well from job to job. For somebody building a career in the Microsoft world, that's a real advantage. You don't need to master it overnight, and nobody expects you to. Being able to open a workflow file and explain what it does is a small, portable skill, and it comes up in more conversations than you'd expect. What it costs before you commit to anything, you want to know the price. So let's deal with that directly.

11:59 GitHub actions is free for public repositories on the standard GitHub machines, and there's no cap on that. If your project is open to the world, you can run as many workflows as you like all month long, and the meter never moves. Private repositories work on an allowance. Instead. On the free plan, you get two thousand minutes a month. The pro and team plans raise that to three thousand, and Enterprise Cloud gives you fifty thousand. Those minutes reset every month. Once you go past them, you pay per minute unless you have no payment method on file, in which case your run simply stop until the next cycle. The per minute rates are small enough to be forgettable. Linux costs about six tenths of a cent per minute, windows costs one cent, and Mac OS costs a little over six cents. Because Apple hardware is expensive to rent at scale, one detail is easy to miss.

12:40 The included minutes are measured in Linux terms, so a heavier operating system eats through your allowance faster, and a ten minute Mac OS build can count for far more than ten minutes of your monthly total. Two more rules round this out. The bigger runners are always billed, even on public repositories, and self-hosted runners don't consume any minutes at all. Because the machine is yours, though, you're still paying for that machine and for the time it takes to keep it running. One small mercy is worth mentioning. Minutes are counted for the time a job actually runs, so a job that fails after five minutes costs you five minutes, not the full build you had planned. A quick recap and one question. Let's bring this back to the simple version, because that's the whole point of this series. GitHub actions is automation built into GitHub, and it runs the tasks you write down whenever something changes in your project.

13:24 Those instructions live in one text file inside a folder called GitHub workflows, and a trigger called on decides what wakes them up. Each job runs on a clean machine called a runner. The steps inside a job run in order, and the building blocks come from a marketplace with thousands of options. Passwords go into secrets, never into the file. And the whole thing is free on public projects. So here's the question I'll leave you with. If you could hand one recurring, boring task to a computer that never forgets and never complains, which task would you pick and why that one?