# GitHub Actions basics > CI is one idea — a check that runs the moment you push, on a machine that isn't yours. GitHub Actions is the instance you happen to be using The idea is decades older than GitHub, so learn the idea and look the YAML up when you need it. Your repository already has a workflow, running since your first push. ## The same verdict at two distances `pnpm check` runs the [checks](https://comp.anu.edu.au/courses/comp4020-agentic-coding-studio/topics/backpressure/#the-roster-wired-into-ci) on your machine in seconds, while the agent still holds the context that produced the mistake. Speed is why it exists locally. CI runs the same command elsewhere and more slowly, answering a different question: does this work anywhere other than the machine it was written on. Uncommitted files, a dependency you installed months ago, an environment variable living in your shell — all invisible locally, all fatal on a fresh runner. That gap is what CI closes. Keep the two aligned. If CI runs something your local command doesn't, you have two results under one name, and you will stop trusting the remote one. The starter keeps them the same on purpose: CI runs your `pnpm check`, plus the handful of things only a runner can reach — your process evidence, internal links, committed secrets, and whether the deployed page is up. ## Reading a red run A red run is a report for you; pasting it to the agent gives it the same report. Paste the log, not only "The build failed". The failing step and its output give the agent a file, a line and an expected-versus-actual. Open the run, find the first red step, and copy what it printed; everything after the first failure is usually collateral. Don't let red become normal. Week 3's fourth property of a good sensor was **trustworthy**, and a permanently failing check spends it: you learn to scroll past the red, and the result stops helping. ## Where it counts for you From the moment `/ship` flips your repo public, CI runs on every push and [the crit sweep reads the result](https://comp.anu.edu.au/courses/comp4020-agentic-coding-studio/topics/studio-crit-model/#in-crit-prototype-marks). The full shipping mark requires a green result when the sweep runs. A red or incomplete result, including no checks at all, receives half. The sweep starts fifteen minutes after the cutoff, which is settling time for exactly this. Your deploy and your checks both need a moment, and a push inside that window spends it. Push early enough that the run finishes. ## What it doesn't settle Everything above is the machine-checkable fraction, run somewhere neutral. It is worth automating because each check handled by the runner leaves you more attention for the questions it cannot settle. It cannot tell you whether the feature works the way a person would want, whether the code is one you'd choose to own, or whether you still understand what the agent built. Green ticks can hide that gap. That last one is [cognitive debt](https://comp.anu.edu.au/courses/comp4020-agentic-coding-studio/topics/evaluating-agent-output/#cognitive-debt). ## The deploy is a check too The full-stack half deploys to [Fly.io](https://fly.io), and the deploy is already in the starter's workflow: once `/comp4020:ship` flips your repo public, CI deploys every push to `main`. See [deploying](https://comp.anu.edu.au/courses/comp4020-agentic-coding-studio/topics/hosting-access/#deploying) for how it works before that, while the repo is private. Once it's wired, a failed deploy is the same kind of signal as a failed test, and [`flyctl`](https://comp.anu.edu.au/courses/comp4020-agentic-coding-studio/topics/hosting-access/#reading-the-running-app) is how you read the running app's logs and status. Source: \ Licence: [CC-BY-NC-SA-4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/)\ Cite as: Swift, B. (2026). _COMP4020/COMP8020 Agentic Coding Studio_ [Course materials]. ANU School of Computing. https://doi.org/10.5281/zenodo.21395760