A Green Tick on Your Pull Request

Open a pull request on almost any real project and something starts happening by itself. A spinner appears beside your commits, runs for a minute or two, and turns into a green tick or a red cross.

Nobody explains this, and a red cross on your first contribution is alarming out of all proportion. So here it is in one page: that is continuous integration, and it is checking your work.

What is actually happening

The project contains instructions, written by somebody once, saying: whenever a change arrives, start a fresh machine, fetch the code, and run these checks.

On GitHub the service that does this is called GitHub Actions, and the instructions live in files inside the repository. Other services do the same job under other names. The important part is that it is automatic, it runs on a clean machine rather than on anyone's laptop, and it happens to every change equally.

What it usually checks

Three things, in most projects.

That the project builds — that the code compiles or the site assembles, on a machine that has none of your local setup.

That the tests pass — the automated checks the project keeps, run against your change to see whether it broke anything that used to work.

That the formatting matches — indentation, quotes, unused imports. Small, mechanical, and much better handled by a machine than by a human reviewer spending attention on it.

Reading the result

Green means every configured check passed. Red means at least one failed, and there is a log saying which.

Open the log and read the last lines first. Build and test output is enormous and mostly uninteresting; the failure is almost always near the end, and it usually names a file and a line.

When it fails on your pull request

It is normal. It happens to everyone, including the people who wrote the checks.

It is also not a rejection: nobody has judged anything. A machine ran a list and one item did not pass. The fix is another commit pushed to the same branch, exactly as in Chapter 8 — and the checks run again automatically, without you asking.

git add style.css
git commit -m "Add the missing closing brace"
git push

Why teams bother

Because the alternative is finding out later. Without checks, a change that breaks the build reaches main, then reaches the live site, and the team learns about it from a user — which is the most expensive possible moment to discover anything.

Running the checks on every proposal moves that discovery to before the merge, when it costs one commit.

What green does not promise

It means the configured checks passed. It does not mean the change is correct, or a good idea, or what anyone asked for.

Checks only test what somebody wrote a test for. That is exactly why review from a human still happens alongside them, and why a green tick is a precondition for merging rather than a reason to merge.

Writing these workflows — what the files look like, how the checks are defined, how a project deploys itself once they pass — is three chapters of the deep dive. This page is what it is; that book is how to build one.