CI/CD with GitHub Actions

When you open a Pull Request, GitHub runs a set of checks on your branch. This is CI — Continuous Integration. After your PR is merged, more automation kicks in to build and prepare your code for release. That part is CD — Continuous Delivery.

You don't trigger any of this yourself — it runs for you, every time. But it's worth being clear about what is running and who set it up: GitHub provides the machinery (servers that can execute code), and we provide the instructions. Those instructions are called workflows, and they live as files inside each repo. Often the platform engineering team writes and maintains the standard set of workflows so every repo gets the same baseline — tests, linting, security scans, container builds — without each team reinventing them.

graph LR
  PR[Open PR] --> CI[CI checks]
  CI --> Merge[Merge to main]
  Merge --> Build[Build container image]
  Build --> Ready[Ready to release]

What "CI" actually checks

The exact checks vary by repo, but you'll typically see:

• Tests — does the code still do what it's supposed to?
• Linting — is the code formatted and styled correctly?
• Security scans — are there any known vulnerable packages?

If any of these fail, the PR shows a red ❌. If all pass, a green ✅.

What to do when CI fails

Don't panic — most failures are small and quick to fix:

1. Click the failed check on the PR to see the full error message.
2. Read the error — it usually tells you what's wrong (missing test, formatting issue, type error).
3. Fix the issue — adjust the code to address what CI flagged.
4. Commit and push — CI re-runs automatically on the new commit.

Common fixes: run the linter locally, fix failing tests, update types. Ask a colleague or use debugging tools if you're stuck after a couple of attempts.

Don't merge a PR with red checks, even if the failure looks unrelated to your change. A red check is the system telling you something is wrong; figure out what before moving on.

GitHub Actions in one paragraph

The system GitHub uses to run these jobs is called GitHub Actions. Think of it as: we hand GitHub a recipe, GitHub provides the kitchen and the cook. The recipes are the workflow files you'll find in .github/workflows/ in each repo. You don't need to edit these — the platform engineering team usually owns them — but knowing they're written by humans (not magic) helps when something behaves unexpectedly.

From merge to a build

Once your PR is merged into main, a workflow runs that turns your code into a container image — a portable, runnable package. The next article explains what that means and how Orca picks it up.

Key takeaway

Treat CI as a safety net you don't have to think about. Green means safe to merge. Red means stop and investigate (or ask for help) before pushing on.