Module 8: Capstone The Andes Cargo Pipeline

5. What only a real GitHub account shows

Description

This guide held, since Module 1, to a hard rule: nothing gets simulated in prose — if something appears as executed, it really ran with act, against the same Docker and the same LocalStack you used in every lesson. That same rule demands, at the guide's close, saying with equal precision which part of this whole pipeline never really ran, because it depends on infrastructure that only exists inside github.com's servers — not a limitation specific to this guide, but of act as a tool, confirmed with exact quotes in the modules where each case showed up. This lesson doesn't repeat those quotes in detail —you already saw them in full at the time—: it brings them together in one place, as the final honesty summary anyone using this repository as a portfolio should be able to recite without hesitation.

Connection to the module

This lesson executes nothing — it's, on purpose, the consolidation of three honesty pieces you already built separately, in Modules 4 and 6: OIDC (shown, not executed), Environments with approval (confirmed that act ignores them), and branch protection (repository configuration, with no YAML act can read). Lesson 6 changes nature: instead of "this didn't run here," it traces the boundary of "this wasn't built at all in this guide."

Analogy: the flight simulator, and the day you have to fly the real plane

act is, as Module 1 already established, a flight simulator for this pipeline: it runs the same maneuvers, with the same YAML, without ever boarding the real plane. A flight simulator is a genuine training tool —a pilot who masters the simulator masters most of what they need to know—, but there's a handful of things a simulator, by design, can't reproduce: the physical sensation of gravity in a sharp maneuver, the real weight of a decision when there's no "reset" button if something goes wrong. This lesson is the moment to precisely name which specific pieces those are for Andes Cargo's pipeline —not to scare anyone with "you still have a long way to go," but so you know exactly what to expect the day you fly the real plane.

The three pieces, summarized with their exact quote

1. Real comments on a Pull Request

Module 3, lesson 7, showed the real market pattern —commenting the plan directly on the Pull Request via actions/github-script— in complete YAML, quoted from HashiCorp's documentation, and executed its real available equivalent under act: writing that same plan to $GITHUB_STEP_SUMMARY, which does work under act and produces a real Markdown summary. The difference isn't in content —the text you'd see in both cases is essentially the same plan— but in where that evidence lives: a PR comment requires the GitHub API to have a real PR number, assigned by github.com, to write against. act, running locally with no real remote repository, doesn't have that number — the "number": 42 (or 52, or 45) in every pr-event.json in this guide is a value you wrote, not one GitHub assigned.

2. Real human approval of an Environment

Module 4, lesson 6, proved it with a real run, not just a claim: act workflow_dispatch -j deploy-to-production on a job with environment: production declared ran end-to-end in 1.6 seconds, with no pause, without waiting for any required reviewer — the practical confirmation of an issue opened and labeled confirmed/not-planned in act's own repository (nektos/act issue #1714). apply.yml, as it stands in this guide, doesn't explicitly declare environment: production —an honest limitation of this specific project, not of GitHub Actions's syntax—, but even if it did, act still couldn't prove the block: the only way to see a real run paused, waiting for a person to approve from a real notification, is with a real repository on github.com.

3. Real branch protection

Module 6, lesson 4, was explicit from its first line: branch protection is repository configuration —Settings → Branches—, not a workflow. There's no YAML act can interpret for this piece, whatever its content. You already have the complete click-path documented precisely (Require a pull request before merging, Require status checks to pass before merging, with the exact terraform-checks job name) — the only thing this guide can't give you is the experience of attempting a direct git push to main and watching GitHub reject it with its own error message.

The summary table, in one place

Piece	Where it was shown	Exact quote	What DID run in this guide
Real PR comment	Module 3, lesson 7	Requires a PR number assigned by the GitHub API, which `act` doesn't have	The same content, published in `$GITHUB_STEP_SUMMARY`
Environment approval	Module 4, lesson 6	`nektos/act` issue #1714, `confirmed/not-planned`	A real `act` run confirming the job does NOT pause
Branch protection	Module 6, lesson 4	Repository configuration, with no associated YAML	The exact click-path, documented step by step
Federated OIDC	Module 4, lesson 5	`nektos/act` discussion #2029: "That's impossible, because only GitHub Actions from github.com can sign the token"	The complete YAML, the IAM trust policy, explained without executing

The fourth row —OIDC— was already precisely summarized in Module 4; it's included here so this table is the complete summary, not a partial list. Notice the pattern common to all four rows: in no case is the reason "this guide didn't have time" — each has a different, cited, verifiable root technical cause, and none gets solved with more effort within this guide's $0 scope.

The optional pointer: creating a real repository, if you want to see it live

None of the above is an obstacle if you want to experience these four pieces with your own eyes — it's optional, never mandatory to complete this guide, and needs no spend: GitHub offers free public repositories, with GitHub Actions included, with no credit card required.

If you wanted to do it, the path would be, in general terms:

Create a new public repository on github.com (free, no Actions minutes limit for public repositories).
Push the same andes-cargo-infra/ you built in this guide —the same ci.yml/apply.yml/drift.yml, without changing a single line, because act guarantees that YAML is the same one that would run in production.
Configure Settings → Branches with Module 6, lesson 4's branch protection rules.
Configure Settings → Environments with a production Environment with at least one required reviewer (yourself, if you work alone).
Open a real Pull Request, and watch the automatic comment, the approval pause, and the rejection of a direct push to main, each for the first time with your own eyes.

This guide doesn't build this step —it doesn't rewrite any lesson assuming you did it—, because doing it properly is outside its $0 scope: running apply.yml against a real AWS account, even a test one, has a real cost and exposes real credentials, exactly the antipattern all of Module 4 exists to name. If you decide to try it, the honest recommendation is pointing apply.yml at an environment that costs no real money —or leaving it running only up to ci.yml, with no real apply connected to any account— until you complete cloud-security-and-guardrails-guide, the guide that does build end-to-end OIDC against a real account, with the corresponding security guardrails.

Common mistakes

Feeling this lesson "takes away" from everything you already built (expectation-based, this lesson's most important one). What happens: someone, after reading the table's four rows, concludes Modules 1 through 7's work was "just a simulation" and loses confidence in what they learned. How to fix it: every workflow you built —ci.yml, apply.yml, drift.yml, the guardrail— is exactly the same YAML that would run on a real GitHub repository, with no line changed, as this guide's research on act confirmed. The only thing that didn't run were four platform pieces (PR comments, human approval, branch protection, OIDC token issuance), not pipeline pieces. Knowing how to precisely name that distinction is, itself, a real skill an interviewer values.

Trying to "force" one of the four pieces inside act, looking for a hidden flag (workflow-based). What happens: someone, unsatisfied with this lesson's honesty, searches act's documentation for some undocumented flag that solves OIDC or environment:. How to fix it: this lesson's four limitations have a structural root cause, not a pending configuration —act doesn't have GitHub's private key to sign a JWT, has no user backend to pause a job, and branch protection isn't even a concept a workflow executor could represent—. There's no flag that solves this, because it isn't a configuration problem.

Creating the real repository "halfway," without deciding what points to a real AWS account (security-based, this pointer's concrete risk). What happens: someone follows this lesson's optional pointer, correctly configures branch protection and Environments, but connects apply.yml to real AWS credentials "to test it fully," without having completed cloud-security-and-guardrails-guide. How to fix it: this guide's test/test dummy credentials are acceptable only because the destination is LocalStack — never use those same credentials, or any long-lived access key, against a real AWS account. If you want to see apply.yml applying against something real, the right path is completing the sister guide's OIDC pattern first.

Exercises

Exercise 1 — Recite the four pieces and their root cause, without looking at the table. From memory, name this lesson's four pieces and, for each one, the exact technical reason —not "because act is limited" in general, but the specific cause— why it doesn't run under act.

See solution

1. Real PR comment — requires a PR number assigned by the GitHub API; act, with no real remote repository, doesn't have that number. 2. Environment approval — act doesn't implement environment:'s protection at all (issue #1714, confirmed/not-planned); the job runs as if that line didn't exist. 3. Branch protection — it isn't a workflow, it's repository configuration in Settings → Branches; there's no YAML act could execute for this, whatever its content. 4. Federated OIDC — signing the JWT depends on cryptographic infrastructure exclusive to real github.com (act doesn't have GitHub's private key), and even if it did, LocalStack doesn't validate OIDC against any real account.

Exercise 2 — Distinguish "pipeline" from "platform" in your own words. A colleague, after reading this lesson, asks: "so, what does actually work for real?" Answer them in two or three sentences, using this lesson's distinction.

See solution

A complete answer sounds, roughly, like this: "Everything that lives inside a .yml file in .github/workflows/ —the steps, the guardrail's logic, how a plan passes from one job to another— is pipeline, and it really ran, with act, in every lesson in this guide. What didn't run are four platform pieces —github.com functions that exist outside any YAML file, like approving a deployment, commenting on a PR, or blocking a direct push—, because act simulates running a workflow, not GitHub's complete servers."

Exercise 3 — Decide whether it's worth creating the real repository, for your own case. With no single correct answer: in what scenario do you think it would make sense, for you, to follow this lesson's optional pointer right now, and in what scenario would it make more sense to wait until completing cloud-security-and-guardrails-guide first?

See solution

A reasonable criterion: if your goal is seeing the PR comment, the approval pause, and the branch protection rejection with your own eyes —with nothing connected to a real AWS account, leaving apply.yml unrun or pointed at an environment that never applies anything—, it makes sense to do it now, it's free and low-risk. If your goal includes seeing a real apply complete against real infrastructure, this lesson's honest recommendation is waiting for cloud-security-and-guardrails-guide: connecting real AWS credentials to a repository before understanding end-to-end OIDC is exactly the kind of rushed decision all of Module 4 exists to prevent.

Summary and next step

In this lesson you consolidated this guide's four pieces that depend on infrastructure exclusive to real github.com —PR comments, Environment approval, branch protection, and federated OIDC—, each with its root technical cause cited from the module where it first appeared. You confirmed the distinction isn't "this guide is incomplete" but "pipeline genuinely works, platform requires real github.com," and saw the optional —never mandatory— path to experience the first three pieces with a free public repository, with the explicit warning against connecting real AWS credentials without having completed the security guide first.

Before moving on you should be able to: recite the four pieces and their root cause without looking at the table; explain the distinction between "pipeline" and "platform" in your own words; and decide, for your own case, whether following this lesson's optional pointer makes sense now or later.

Lesson 6 traces a different, broader boundary: not what this guide couldn't execute because of a technical act limitation, but what this guide, by design, never set out to build — the complete security of a real production pipeline.

Resources

nektos/act discussion #2029 — the source for the quote about why act can't issue OIDC tokens, already cited in full in Module 4.
nektos/act issue #1714 — the source for the quote about why act ignores environment:, already cited in full in Module 4.
GitHub Docs — About protected branches — official branch protection documentation, already cited in Module 6.
GitHub Docs — Actions billing and usage — confirms public repositories don't consume paid GitHub Actions minutes, the basis for this lesson's optional pointer.

← Previous4. End-to-end walkthrough: a rejected change Next →6. The security this guide didn't build