You have spent five modules using GitHub Actions: you have written ci.yml, cd.yml, rollback.yml and infra.yml, you have extracted the prepare-node composite action and the reusable-build-publish.yml reusable workflow, you have federated credentials with OIDC and you have set up concurrency and matrices with sharding. What you have not done is look at the tool as a tool: what exactly happens between somebody pushing a commit and a runner starting, what contexts exist and which are available when, what triggers there are beyond push and pull_request, how you write your own action when the existing ones fall short, what the real service limits are and what to do when you hit them. This lesson closes those gaps. It does not re-explain what a cache is or what an immutable artifact is — that is in 04-02 and 02-06 — it explains how GitHub Actions materialises them, where intuitions break, and what trade-offs come with the tool the course has been using by default. Because the module promised there would be no fanaticism, and that applies to the home tool too.

1. The full life cycle of an event and where the state lives
2. Contexts and expressions in depth
3. All the triggers that were missing
4. pull_request versus pull_request_target
5. GITHUB_TOKEN, permissions and OIDC
6. The three types of action, with a complete JavaScript action
7. Advanced matrices and dynamic matrices
8. Flow control: outputs, continue-on-error, timeout-minutes, concurrency
9. Cache and artifacts: keys, limits and eviction
10. Self-hosted runners and autoscaling with ARC
11. Summaries, annotations and workflow commands
12. Environments, rules and deployments
13. Real service limits and strategies
14. Debugging and testing workflows
15. Common Mistakes and Tips
16. Exercises
17. Conclusion

Five details that explain behaviours many people find either magical or broken:

Which branch the workflow is read from. For push and pull_request, from the commit that triggers it. But for schedule, workflow_dispatch and workflow_run it is read from the default branch, always. That is why a new schedule does not run until the change reaches main, and why a workflow_dispatch you fix on a branch still misbehaves when you launch it.

The definition is frozen at start-up. If you push a change to the workflow while a run is in progress, that run carries on with the old version. It is useful for reasoning about in-flight runs.

Each job is a new machine. Nothing persists between jobs except what you pass explicitly: outputs, artifacts or cache. What does persist between steps of the same job is the file system — but not the shell process (each run is a fresh shell: an export in one step does not reach the next; that is what $GITHUB_ENV is for).

The runner arrives empty. There is no automatic checkout — unlike Travis or GitLab — which is why actions/checkout is always the first step, and why forgetting it produces the most repeated "no such file or directory" error in the tool.

The result is published as checks on the commit, and it is those checks that the branch protection from 02-07 requires. A job that does not run because of a false if ends up as skipped, and skipped counts as passing for branch protection: that asymmetry is the cause of the subtlest "false green" in Actions, and we will come back to it.

Contexts are objects available inside ${{ }}. Knowing which ones exist and when they are available avoids half the errors.

1. $GITHUB_OUTPUT is the current mechanism (the old ::set-output was withdrawn for security reasons). For multi-line values you need a delimiter:

   {
     echo "notes<<EOF"
     cat CHANGELOG.md
     echo "EOF"
   } >> "$GITHUB_OUTPUT"
   

2. $GITHUB_ENV defines variables for the later steps of the same job; an ordinary export does not leave the step because each run is a different shell.

Available functions, with their typical uses:

And the details that bite:

Every matrix value and every workflow_dispatch input arrives as a string. if: inputs.force == true is always false if force comes from a workflow_dispatch; you have to compare against 'true' or use fromJSON(inputs.force).

A job-level if does not take ${{ }} (although it works with them); inside an expression, it does.

if: always() versus if: ${{ !cancelled() }}: always() runs the step even if the workflow was cancelled, which can leave resources half-finished or delay the cancellation. For "run even if it fails, but not if it is cancelled" — the usual case of publishing test reports — the correct form is if: ${{ !cancelled() }}.

Secrets are not available in a workflow-level if, and you cannot use them to decide whether a workflow runs either. The pattern for "only if there are credentials" is a preceding job that checks them and exposes a boolean output.

Beyond push and pull_request:

Two specific patterns that come up a lot:

The author_association check is essential: without it, anybody on the internet can trigger a deployment by writing a comment. And the comment body is never interpolated inside run:, because that is a direct script injection (04-03): if you need to read it, pass it through env: and treat it as data.

The most important security distinction in the whole tool. Lesson 04-03 stated it; here is the full mechanism.

An npm ci runs the postinstall scripts from the PR's package.json. An attacker opens a PR with a postinstall that sends process.env to their server, and walks off with every secret. This is not theoretical: it is the most common way public repositories get compromised.

The rules, without nuance:

1. Use pull_request by default. It covers 95 % of cases.
2. Use pull_request_target only when you need secrets or write access from forks — labelling, commenting, formatting — and without checking out the PR code.
3. If you need both things (building a fork's code and commenting on the result), split it: a pull_request workflow builds without secrets and uploads an artifact; a second workflow with workflow_run downloads it and comments. The second one has secrets but never runs the fork's code.
4. GITHUB_TOKEN with minimum permissions always, and above all here.

Applied to a private repository like Reservalia's, the risk is lower — only the team opens PRs — but not zero: one compromised account is enough. And if a repository is ever made public, the workflows travel with it.

Each job receives an ephemeral GITHUB_TOKEN that dies with it. Its scope depends on the organisation's configuration — the default value can be permissive in older repositories — and on what you declare:

Points that matter:

• Declaring permissions at workflow level sets everything to what you declared, not only what is listed: if you put contents: read, the rest are set to none. That is what you want.
• Job permissions replace, they do not accumulate. A job with permissions: { pull-requests: write } loses contents: read and the checkout fails.
• GITHUB_TOKEN does not trigger other workflows. A push made with it does not launch the on: push, by design, to avoid infinite loops. If you need to chain, use a GitHub App or a PAT — with the caveat that then you really can create a loop.
• OIDC (id-token: write) is what 03-02 established: the runner asks for a signed token with claims about repository, branch, environment and flow, and AWS exchanges it for temporary credentials. The IAM trust condition must bind sub precisely:

  "StringLike": { "token.actions.githubusercontent.com:sub": "repo:reservalia/reservalia:environment:production" }
  

  Writing repo:reservalia/* or leaving sub with broad wildcards cancels out most of the protection: any branch of any repository in the organisation could assume the role. It is a frequent and serious configuration mistake.

You already wrote the composite one in 04-05. Here, a complete JavaScript action: it checks the bundle size budget and publishes the result, a real Reservalia case (05-01).

1. getBooleanInput parses 'true'/'false' correctly. getInput('fail') === true would always be false: every input arrives as a string, which is the same trap as in section 2.
2. core.setOutput publishes outputs consumable with steps.<id>.outputs.<name>.
3. core.summary writes to $GITHUB_STEP_SUMMARY: markdown that appears on the job page (section 11).
4. core.setFailed marks the step as failed with a message; core.warning and core.notice create annotations without failing. With file, startLine and endLine the annotation is anchored to a specific line of code, which is what makes linters useful in the diff view.
5. A global catch: without it, an exception produces a failure with a raw, hard-to-read stack trace.

One more function worth knowing: core.setSecret(value) registers a value so that it is masked in the logs from that moment on. It is essential when your action computes or receives a secret that did not come from secrets — a token obtained from an API, for example. And with the same warning as in 06-01 and 06-04: masking covers the literal match, not transformations of it.

An operational detail that catches people out: a JavaScript action needs its dependencies committed to the repository, because the runner does not run npm install. It is bundled with @vercel/ncc (ncc build src/index.js -o dist) and CI checks that dist/ is in sync with src/, or you will publish an action that does not contain your changes.

How to choose: composite if it is commands; JavaScript if there is logic, an API or computed outputs; Docker only if you need awkward system dependencies — accepting that it only works on Linux runners and that it starts slowly.

1. fail-fast: true (the default) cancels the whole matrix on the first failure. It saves minutes and hides information: if you wanted to know whether it fails on Node 20 and on Node 22, set it to false. Rule of thumb: false for compatibility matrices, true for shards of the same suite.
2. max-parallel limits the concurrency: useful when the matrix hits a shared resource (a test database, an API limit).
3. include has two behaviours and that is where the confusion lies: if its keys match an existing combination, it adds properties to that combination; if it does not match, it creates a new combination.
4. exclude is applied afterwards, once everything has been expanded, including the includes.

A dynamic matrix, which is the pattern that solves the monorepo from 04-04:

1. An empty matrix makes the job fail, it does not skip it. Hence the has-changes output and the if.
2. fromJSON turns the string into a real array for the matrix.
3. The gate job is the key piece and the one almost nobody adds. Because matrix jobs have dynamic names, they cannot be required by name in branch protection; and because a skipped job counts as passing, without this gate a PR where the tests are skipped due to a detection bug would sail through protection with everything green. It is the "false green" of 04-04 in its most treacherous form: there is nothing red to look at. gate does have a fixed name, always runs (if: always()) and checks needs.test.result explicitly.

1. timeout-minutes on every job, without exception. The default value is 6 hours: a hung job burns billable minutes for that entire time and blocks a concurrency slot. It is a line that saves real money.
2. continue-on-error: true lets the step fail without breaking the job. It also exists at job level.
3. outcome versus conclusion: outcome is the result before applying continue-on-error; conclusion is the final result. With continue-on-error, conclusion is success even though outcome is failure. To detect that something failed but did not block, look at outcome.
4. Two different uses of concurrency, and it is best not to mix them. For CI: group: ci-${{ github.ref }} with cancel-in-progress: true, to cancel stale runs and save money (04-04). For deployments: cancel-in-progress: false and a global group, to serialise and avoid two simultaneous deployments to the same environment. Cancelling a deployment halfway through is far worse than waiting.

One detail that confuses people: with concurrency, only the most recent waiting run is kept; the intermediate ones are cancelled. In a serialised deployment, if three commits pile up, the first and the last get deployed and the middle one never does. That is usually what you want, but you need to know it.

1. The key must contain everything that invalidates it: operating system, architecture if it varies, and the hash of the lockfiles. hashFiles accepts multiple patterns.
2. restore-keys are fallback prefixes: without them, any lockfile change forces a full download.
3. cache-hit is 'true' only on an exact match; a partial restore via restore-keys leaves cache-hit as false even though it restored files. Making npm ci conditional on cache-hit is a classic mistake.

Cache behaviour rules that are not obvious and explain a lot of oddities:

• The cache is scoped to the branch. A branch can read its own caches and those of its base branch; not those of sibling branches. That is why the first run of a PR tends to be slower and why it pays to have main populate the cache.
• Caches are immutable: once a key is written, it is not overwritten. To invalidate, change the key (a versioned prefix helps).
• There is a total size limit per repository and least-recently-used eviction applies; on top of that, caches unused for a while are removed. Practical consequence: caching several gigabytes per branch makes them evict each other and the hit rate collapses. Less, better chosen, performs better.
• The cache is not a secure channel between branches. A PR can write to a cache that another run later restores. Do not cache built binaries that are then executed with privileges (04-03).

Artifacts:

1. In v4 artifact names must be unique within the run: uploading the same name from several matrix jobs fails. It is a change from v3 that breaks many inherited workflows.
2. retention-days saves billable storage; the policy from 02-06 in one line.
3. pattern with merge-multiple reassembles the reports from every shard in an aggregation job.

And one difference from the cache worth keeping in mind: artifacts are uploaded and downloaded over the network from the service, not from the runner, so large artifacts cost time at both ends. Passing node_modules between jobs as an artifact is usually slower than reinstalling from cache.

Runners are organised into groups (per organisation) to restrict which repositories can use them — essential if a runner has access to a sensitive network.

The serious risk, and it has to be said plainly: never use self-hosted runners on public repositories. Anybody can open a PR whose workflow runs arbitrary code on your machine, inside your network. And if the runner is persistent, that code can leave things behind for the next job — including another team's. GitHub warns about it explicitly and the warning is ignored far too often.

ARC (Actions Runner Controller) solves the persistent runner problem by running one ephemeral Pod per job on Kubernetes, which is exactly the model from 06-05:

1. minRunners: 1 keeps one runner warm: without it, the first job of the morning pays the full Pod start-up. It is the trade-off between cost and queue time that 04-04 asked you to measure separately.
2. containerMode: kubernetes avoids privileged Docker-in-Docker and uses Pods for service containers, with the security implications from 06-05.

Honest trade-offs of ARC: it is one more component to operate and update; the Pod start-up adds queue time; and the cache does not persist between Pods, so you depend on a remote cache. In exchange: a clean environment per job, autoscaling, and cost proportional to usage on your own infrastructure.

A pipeline whose result you have to hunt for in 4,000 lines of log is a pipeline nobody looks at (03-06). Three mechanisms fix it:

The job summary is the best readability investment you can make in a pipeline for little effort: a link to the preview, the published digest, the bundle budget result and the failing tests in a table save Nuria from opening logs every time. And ::add-mask:: is the equivalent of core.setSecret for shell scripts: if your script derives a token, mask it before it can appear in any output.

1. The URL appears in the deployments interface and on the PR.

What an Environment gives you, which is more than it seems:

• Required reviewers: the job waits for human approval. It is the gate from 03-01, and a waiting job does not consume a runner — a notable difference from Jenkins' input (06-01).
• Wait timer: mandatory minutes before deploying, to give room to cancel.
• Allowed branches and tags: only main can deploy to production, even if somebody modifies the workflow on another branch.
• Per-environment secrets and variables: secrets.DATABASE_URL means one thing in staging and another in production, with no conditionals in the YAML.
• Deployment history per environment with its commit.
• And the piece that matters most combined with OIDC: the token's sub claim includes the environment, so the production IAM role can only be assumed from a job with environment: production, which in turn can only run from main and after approval. Three chained controls instead of one.

No fanaticism, not even with the home tool. The specific values change with the plan and over time — check them before designing — but the types of limit and their strategies are stable:

Two conceptual limits, more important than the numeric ones:

• The control plane is GitHub's. If the service has an incident, you do not deploy — not even with your own runners. It pays to have a documented emergency path: a script that deploys from a machine with temporary credentials, rehearsed. It is the same reasoning as 03-05 applied to the tool.
• Depending on the third-party actions ecosystem is a supply surface. It is its greatest strength and a real risk: pin by SHA (04-03), review what you add, and prefer CLI commands when the action only wraps one.

Notes from real use: ACTIONS_STEP_DEBUG shows what inputs each action receives and what expressions evaluate to what, and it resolves most of the "why is this if not met?" cases. toJSON(github.event) is the fastest way to discover the exact name of a payload field. tmate opens an interactive session on a runner with the job's secrets: use it only in private repositories, with timeout-minutes and preferably in a job without production credentials; it is the same reasoning as SSH into build from 06-03.

And act: useful for iterating on a job's logic, but it does not reproduce the environment. It does not implement caches, services, token permissions, OIDC or environments the same way, and its images are not GitHub's. It is good for "does my script work?", not for "is my workflow correct?".

For the latter, the strategy from 04-05 is still the right one: actionlint in CI itself to catch syntax and expression errors before merging, a test branch where you exercise the whole workflow, and progressive changes with the new pipeline running alongside the old one.

Forgetting actions/checkout. The runner arrives empty. It is everybody's first mistake.

Expecting export to travel between steps. Each run is a new shell: use $GITHUB_ENV.

Comparing boolean inputs against true. They arrive as strings. == 'true' or fromJSON(...).

Job-level permissions believing they add up. They replace: if you put pull-requests: write without contents: read, the checkout fails.

pull_request_target with a checkout of the PR code. It is the most direct way to leak all your secrets.

An OIDC sub with broad wildcards. repo:org/* lets any repository in the organisation assume your production role. Bind repository, branch or environment.

No timeout-minutes. The default is 6 hours of billable minutes for a hung job.

fail-fast: true in compatibility matrices. It cancels and hides the very information you were after.

A dynamic matrix without a gate job. Skipped jobs count as passing in branch protection: false green with nothing red to look at.

Making the install conditional on cache-hit. A partial restore leaves cache-hit as false; and even if it matched, npm ci is still necessary.

Caching node_modules. Binaries tied to a version and an architecture, and it eats the repository's cache budget, evicting useful caches.

Self-hosted runners on public repositories. Arbitrary code execution inside your network.

Third-party actions not pinned by SHA. A tag is mutable: whoever controls the action's repository controls your pipeline (04-03).

Repeated artifact names in a matrix with v4. The upload fails; use a suffix with the index.

if: always() to publish reports. It also runs on cancellation. Use if: ${{ !cancelled() }}.

Exercise 1. Write a JavaScript action verify-migrations that, given a migrations directory, checks three things: that there are no two files with the same version number, that no new migration in the PR contains DROP COLUMN or DROP TABLE (the expand and contract rule from 04-06), and that every migration has its rollback file. It must expose outputs, write a job summary, generate annotations anchored to the file and be configurable as blocking or informational.

Exercise 2. A public Reservalia repository has this workflow. Find every security problem, explain the impact of each one and rewrite it:

Exercise 3. Reservalia's ci.yml takes 11 minutes and the team complains that "GitHub Actions is slow". The data: average queue time is 4 minutes between 10:00 and 12:00; the six jobs restore cache but the hit rate is 40 %; the test matrix has fail-fast: true and often gets cancelled because of a flaky test; three jobs have no timeout-minutes and one of them hangs a couple of times a week; and the repository's total cache is at the limit with 9 GB, most of it node_modules from old branches. Diagnose each point and give an ordered plan.

Solution 1.

Design decisions worth justifying. Duplicate numbering is checked across the whole directory, because the collision can come from two PRs open in parallel that are individually correct — it is an integration problem, not a file problem. Destructive operations and rollback files are checked only on the new migrations, because the historical ones have already been applied and flagging them would be noise that makes people ignore the tool. The fail input allows the progressive rollout from 04-05: informational for two weeks first, to measure how much noise it generates, then blocking. And the annotations anchored to file and line appear in the diff view, where the reviewer sees them without opening logs. Using it requires fetch-depth: 0 and passing base: ${{ github.event.pull_request.base.sha }}.

Solution 2. Six problems, three of them serious:

Rewritten as two workflows, which is the correct pattern:

The central idea: separate privilege from the execution of untrusted code. The first workflow runs the PR's code with no secrets at all and read-only permissions; the second has write permission but only processes data that has already been generated and never runs the fork's code. Note as well that the PR title disappears from the comment: it added nothing and it was the injection vector. And that the data is passed through env, not interpolated into the script body, which is the general rule for any externally sourced data.

Solution 3. The diagnosis separates two things the team is conflating: 11 minutes of execution and 4 of queueing are different problems with different causes, and calling it all "GitHub Actions is slow" prevents fixing either.

Order and reasons. Point 1 first, because it costs five minutes of work and it is a partial cause of point 3: hung jobs occupying concurrency slots are part of the queue. Then 2, which is the biggest time saving per unit of effort and also frees up cache budget. Then 4, with the important caveat: fail-fast: false reduces the symptom but the real problem is the flaky test, and leaving it unquarantined while hiding the symptom is exactly what 02-04 warned against. And only then 3 and 5, once you can measure how much of each remains.

What to take away: of the five points, three are not about the tool — a flaky test without quarantine, jobs without timeouts, a badly chosen cache — but about how it is being used. The conclusion to take back to the team is that before changing tool or paying for more concurrency, you have to separate queueing from execution and fix your own side, which is literally the first rule of 04-04. If after that the queue is still the bottleneck, then there really is a legitimate conversation about the plan or your own runners, and that conversation is had with data.

GitHub Actions has been the course's tool since module 2, and this lesson has finally looked at it as an object of study. What closes the gaps that were left: the life cycle of an event and which branch the workflow is read from — which explains why schedule and workflow_run behave the way they do; contexts, with the trap that every input is a string; the triggers that were missing and the golden rule of pull_request versus pull_request_target; permissions that replace rather than accumulate, and the OIDC sub that has to be bound precisely; the three types of action and when to drop down to JavaScript; dynamic matrices with their mandatory gate job; the real behaviour of the cache with its per-branch scope and its eviction; ARC for ephemeral runners; and the service limits with their strategies.

The trade-offs, said plainly, because the module promised not to do marketing for any tool: the control plane is not yours and a service incident leaves you unable to deploy; the third-party actions ecosystem is its greatest strength and a real supply surface; the cache has a per-repository budget that punishes excess; schedule is not punctual and switches itself off; there are dangerous asymmetries such as a skipped job counting as passing; and pull_request_target is a permanent war footing in public repositories. None of that makes it a bad choice — for a team whose code is already on GitHub it remains the most reasonable default — but knowing these things is the difference between using it and suffering it.

That completes the tour of all six tools and the same Reservalia pipeline translated six times. The lesson that closes the module, Comparison and Criteria for Choosing a Tool, puts everything on the same table: the vocabulary equivalence table, the comparison by dimensions — execution model, hosting, reuse, identity, cost — the decision criteria ordered by their real weight (with one factor that decides 80 % of cases), a decision tree, a total cost of ownership exercise, the cost of switching tools and how to reduce it, and a phased migration guide. And after that, module 7: building your own end-to-end pipeline.