Episode 2 — Who Actually Runs My Pipeline? Junior Engineer: Last week you left me hanging. I push code, GitHub gets it — then what? Whose computer is actually running my tests? Senior Engineer: Hones
By Coderz Club · 2026-08-03 · Tags: git, go
Episode 2 — Who Actually Runs My Pipeline?
Junior Engineer: Last week you left me hanging. I push code, GitHub gets it — then what? Whose computer is actually running my tests? Senior Engineer: Honestly, most engineers use this stuff for months without ever asking that question. Good that you did. The Push Senior Engineer: Let's slow it down. You type git push. What actually leaves your machine? Junior Engineer: The code, I guess? My commits? Senior Engineer: More specific than that. Git doesn't upload your whole project every time — it sends only what's changed, packed into a compact Git-native format. Not a ZIP of your folder. Just the new commits, efficiently. Junior Engineer: I've never thought about what the wire format looks like. Senior Engineer: And you don't need to, not for this. Git internals are their own series — we'll get there. All you need today is: your commits arrive. Point is — your commits arrive. GitHub stores them. The branch pointer updates. Your PR, if there is one, now shows a new commit. Junior Engineer: And then a pipeline starts? Senior Engineer: No. Not yet. Something has to tell it to start. The Webhook Senior Engineer: GitHub doesn't inherently know that your repo cares about pushes. GitHub runs millions of repos. Most of them don't have CI. So after storing your commit, GitHub does one thing: it fires an event. Internally, this looks like a notification — "hey, a push event just happened on this repo, on this branch, here are the commit details." GitHub then checks: does anyone care about this event? Junior Engineer: Who's "anyone"? Senior Engineer: Anyone who registered a webhook. A webhook is just a URL that says "when X happens, send an HTTP POST to this address with the details." External services register webhooks on your repo all the time — Slack bots, monitoring tools, deployment services. And GitHub's own CI system, GitHub Actions, effectively registers one too. Junior Engineer: So GitHub Actions is... listening through a webhook like everything else? Senior Engineer: Conceptually, yes. Under the hood it's more integrated than a third-party webhook — GitHub doesn't literally POST to itself over the internet — but the mental model holds. An event occurs, something is listening, and that something decides what to do next. 📝 Production Note Webhooks are how most modern systems communicate about "something happened." Stripe uses them to tell your server a payment succeeded. Twilio uses them to deliver incoming SMS. GitHub uses them to notify CI systems that a push occurred. The pattern is always the same: event source, HTTP POST, payload with details, receiver decides what to do. 🎤 Explain It In One Minute Imagine you're explaining GitHub Actions to a teammate — without using the words webhook, runner, or workflow. Can you explain what happens after git push? If yes — you understand the idea, not just the terminology. Workflow Discovery Junior Engineer: Okay, so the push event fires. What does GitHub Actions do with it? Senior Engineer: It does something surprisingly simple. It looks at your repo. Specifically, it checks for a directory: .github/workflows/ If that directory doesn't exist — nothing happens. Your push lands, your branch updates, and that's the end of it. No pipeline. No runner. No tests. Silence. Junior Engineer: What if the directory exists but is empty? Senior Engineer: Same thing. GitHub looks for workflow files inside that directory — YAML files, specifically — and checks whether any of them are configured to trigger on a push event. If none match, silence again. Junior Engineer: So the workflow file is what actually connects the push to the pipeline. Senior Engineer: Exactly. The event is just noise until a workflow file says "I care about this." What Is a Workflow? Junior Engineer: Before we go further — what actually is a workflow, conceptually? Not the YAML syntax, but the idea. Senior Engineer: A workflow is a description of: "when this event happens, run these steps, in this order, on this type of machine." That's it. Three things: Trigger — what event starts it? A push? A PR? A manual button click? A schedule? Jobs — logical groupings of steps. A "test" job, a "build" job, a "deploy" job. Steps — the actual commands. npm ci, npm test, docker build, whatever your project needs. Junior Engineer: And all of that lives in one YAML file? Senior Engineer: One YAML file per workflow. A repo can have many workflows — one for PRs, one for deploys, one for nightly cleanup, whatever you need. Each is independent. Why YAML? Junior Engineer: Why YAML, though? Why not just a JavaScript file or a Python script that says what to run? Senior Engineer: Few reasons, and they're all about trust and constraint. First — a JS or Python file is executable. It can do anything. Delete files, make network requests, mine crypto. You're handing GitHub a script and saying "run this on your machines." That's a hard sell at GitHub's scale — millions of repos, many of them pu
Junior Engineer: Last week you left me hanging. I push code, GitHub gets it — then what? Whose computer is actually running my tests? Senior Engineer: Honestly, most engineers use this stuff for months without ever asking that question. Good that you did. The Push Senior Engineer: Let's slow it down. You type git push. What actually leaves your machine? Junior Engineer: The code, I guess? My commits? Senior Engineer: More specific than that. Git doesn't upload your whole project every time — it sends only what's changed, packed into a compact Git-native format. Not a ZIP of your folder. Just the new commits, efficiently. Junior Engineer: I've never thought about what the wire format looks like. Senior Engineer: And you don't need to, not for this. Git internals are their own series — we'll get there. All you need today is: your commits arrive. Point is — your commits arrive. GitHub stores them. The branch pointer updates. Your PR, if there is one, now shows a new commit. Junior Engineer: And then a pipeline starts? Senior Engineer: No. Not yet. Something has to tell it to start. The Webhook Senior Engineer: GitHub doesn't inherently know that your repo cares about pushes. GitHub runs millions of repos. Most of them don't have CI. So after storing your commit, GitHub does one thing: it fires an event. Internally, this looks like a notification — "hey, a push event just happened on this repo, on this branch, here are the commit details." GitHub then checks: does anyone care about this event? Junior Engineer: Who's "anyone"? Senior Engineer: Anyone who registered a webhook. A webhook is just a URL that says "when X happens, send an HTTP POST to this address with the details." External services register webhooks on your repo all the time — Slack bots, monitoring tools, deployment services. And GitHub's own CI system, GitHub Actions, effectively registers one too. Junior Engineer: So GitHub Actions is... listening through a webhook like everything else? Senior Engineer: Conceptually, yes. Under the hood it's more integrated than a third-party webhook — GitHub doesn't literally POST to itself over the internet — but the mental model holds. An event occurs, something is listening, and that something decides what to do next. 📝 Production Note Webhooks are how most modern systems communicate about "something happened." Stripe uses them to tell your server a payment succeeded. Twilio uses them to deliver incoming SMS. GitHub uses them to notify CI systems that a push occurred. The pattern is always the same: event source, HTTP POST, payload with details, receiver decides what to do. 🎤 Explain It In One Minute Imagine you're explaining GitHub Actions to a teammate — without using the words webhook, runner, or workflow. Can you explain what happens after git push? If yes — you understand the idea, not just the terminology. Workflow Discovery Junior Engineer: Okay, so the push event fires. What does GitHub Actions do with it? Senior Engineer: It does something surprisingly simple. It looks at your repo. Specifically, it checks for a directory: .github/workflows/ If that directory doesn't exist — nothing happens. Your push lands, your branch updates, and that's the end of it. No pipeline. No runner. No tests. Silence. Junior Engineer: What if the directory exists but is empty? Senior Engineer: Same thing. GitHub looks for workflow files inside that directory — YAML files, specifically — and checks whether any of them are configured to trigger on a push event. If none match, silence again. Junior Engineer: So the workflow file is what actually connects the push to the pipeline. Senior Engineer: Exactly. The event is just noise until a workflow file says "I care about this." What Is a Workflow? Junior Engineer: Before we go further — what actually is a workflow, conceptually? Not the YAML syntax, but the idea. Senior Engineer: A workflow is a description of: "when this event happens, run these steps, in this order, on this type of machine." That's it. Three things: Trigger — what event starts it? A push? A PR? A manual button click? A schedule? Jobs — logical groupings of steps. A "test" job, a "build" job, a "deploy" job. Steps — the actual commands. npm ci, npm test, docker build, whatever your project needs. Junior Engineer: And all of that lives in one YAML file? Senior Engineer: One YAML file per workflow. A repo can have many workflows — one for PRs, one for deploys, one for nightly cleanup, whatever you need. Each is independent. Why YAML? Junior Engineer: Why YAML, though? Why not just a JavaScript file or a Python script that says what to run? Senior Engineer: Few reasons, and they're all about trust and constraint. First — a JS or Python file is executable. It can do anything. Delete files, make network requests, mine crypto. You're handing GitHub a script and saying "run this on your machines." That's a hard sell at GitHub's scale — millions of repos, many of them pu