CI with GitHub Actions flashcards

Test, build and ship on every push, with pipelines that are fast, cheap and hard to attack.

Beginner friendly, starts from zero

CardsCheatsheetTips and tricks

CI with GitHub ActionsStart from zero · 1 of 12

What is GitHub Actions, in one plain sentence?

Think of the answer, then tap

GitHub is a website where teams keep their code. GitHub Actions is its built-in robot helper that runs , like checking the code, every time someone changes it.

A helper that never forgets to check.

Show again

12 left

Got it

Drag the card: right if you know it, left to see it again, up to skip · Space turn over · K got it · J again · ← back

Tap to turn over. Swipe right if you know it, left to see it again.

All topics

What you will learn

Start from zero
- What CI and GitHub Actions are3 cards
- Git words you need3 cards
- Workflow words4 cards
- Before and after this topic2 cards
Core basics
- How a workflow runs5 cards
- Your first CI workflow5 cards
- Triggers2 cards
- Jobs and runners3 cards
- Protecting main and fixing failures2 cards
Next steps
- Matrix and job flow2 cards
- Secrets, variables and the token4 cards
- Caching and artifacts2 cards
- Expressions and conditions2 cards
- Schedules, filters and concurrency3 cards
- Passing data between steps and jobs2 cards
- Environments and deployment2 cards
- Containers and services2 cards
Go deeper
- Reuse and writing actions4 cards
- Supply chain security5 cards
- Runners and performance4 cards
- Releases and provenance2 cards
- Debugging and reporting3 cards

Final test and certificate

10 questions drawn fresh from the whole topic, about 15 minutes. Sign in, score 80% or more and get a free certificate with your name and a public check link anyone can open, such as an employer or a teacher. Not signed in? Try a practice test from the cards.

Take the final test

About these cards

Reviewed 26 October 2026
CoversGitHub-hosted runners, October 2026 (ubuntu-latest = Ubuntu 24.04)Node 24 action runtimeactions/checkout v7, actions/cache v6, actions/setup-node v7actions/upload-pages-artifact v5, actions/deploy-pages v5

Checked against

How these cards are made

CI with GitHub Actions at a glance

GitHub Actions is a robot helper inside GitHub that tests, builds and ships your code every time it changes.

It is like a quality inspector on a bakery line: every tray of code is checked before it reaches the shop, and a bad tray is stopped with a red mark.

Words you will meet

Repository: A project folder on GitHub that remembers every change
Commit: One saved change with a short note
Pull request: A request for the team to review a branch and join it into main
Workflow: A recipe file that says what to run and when
Job: A group of steps that runs on one machine
Step: One command or ready-made action inside a job
Runner: The fresh computer GitHub lends you to run a job
YAML: The plain text format, with key: value lines, that workflow files use

The steps

1. Start from zero (12 cards): What CI is, the Git and GitHub words you need, and your first seven-line workflow.
2. Core basics (17 cards): Workflows, triggers, jobs, steps and runners: a real CI pipeline from the first line.
3. Next steps (19 cards): Matrices, secrets, the token, caching, artifacts, conditions and the controls that keep CI fast and cheap.
4. Go deeper (18 cards): Reuse at scale, keyless cloud auth, supply-chain and injection attacks, runners, releases and debugging.

All 12 cards in Start from zero

What is GitHub Actions, in one plain sentence?: GitHub is a website where teams keep their code. GitHub Actions is its built-in robot helper that runs jobs, like checking the code, every time someone changes it.
What was life like before tools like this?: Someone had to remember to run the checks by hand before each change went in. People forgot, broken code slipped through, and finding the cause later took hours.
Where have you already seen it at work?: The green tick or red cross next to a change on GitHub comes from it. Many apps you use get tested and released this way, so their updates arrive without a person pressing buttons.
What are a repository, a commit and a push?: A repository (repo) is a project folder that remembers every change. A commit is one saved change with a short note, and a push sends your commits up to GitHub.
What are a branch, main, a pull request and a merge?: A branch is a separate line of work, so you can try things safely. main is the official branch. A pull request asks the team to review a branch, and a merge joins it into main.
What are a test, a build and CI?: A test is a small program that checks your code gives the right answer. A build turns code into the finished thing you ship. CI (continuous integration) runs both automatically on every change.
What are a workflow, a job, a step and an event?: A workflow is one recipe file. It holds jobs, each job is a list of steps done in order, and an event, such as a push, is what starts the workflow.
What are a runner, a virtual machine and a shell command?: A runner is a fresh computer GitHub lends you for each job, usually a virtual machine (a computer made in software). A shell command is a typed instruction, like echo hello, run in its terminal.
What is YAML, the format workflow files use?: YAML is plain text for settings. Each line is a key, a colon, then a value, and indenting with spaces puts one thing inside another.
Your first tiny win: what does this workflow do?: Save it as .github/workflows/hello.yml and push. On push, GitHub starts an Ubuntu Linux runner, and the step prints a greeting in the run log.
What do you need before starting this topic?: A free GitHub account and a browser; nothing to install. Knowing the Git basics (commit, push, branch) helps, and the cards explain the rest.
What will you be able to do after this topic?: Write workflows that test every change, build and release your app, keep secrets safe, run jobs in parallel and keep pipelines fast and cheap.

CI with GitHub Actions cheatsheet

Triggers

on: pull_request: branches: [main] PRs targeting main
on: push: tags: ["v*"] Release on version tags
on: workflow_dispatch: inputs: Manual run button with a form
on: schedule: - cron: "17 3 * * 1-5" Weekdays, time in UTC
on: workflow_call: Make this a reusable workflow
on: workflow_run: types: [completed] Run after another workflow
paths: / paths-ignore: Filter by changed files

Job keys

runs-on: ubuntu-24.04 Pinned runner image
needs: [build, test] Wait for these jobs
if: github.ref == 'refs/heads/main' Only on main
strategy: fail-fast: false Let all matrix jobs finish
timeout-minutes: 15 Kill hung jobs early
environment: production Approvals and scoped secrets
concurrency: cancel-in-progress: true Drop superseded runs

Security

permissions: contents: read Read-only token by default
permissions: id-token: write Allow OIDC cloud login
uses: owner/action@<sha> # vX Pin third-party actions
env: TITLE: ${{ github.event.issue.title }} Pass untrusted text safely
echo "::add-mask::$TOKEN" Mask a derived secret in logs
secrets: inherit Hand all secrets to a callee, use sparingly

Runner files and contexts

echo "tag=v1" >> "$GITHUB_OUTPUT" Set a step output
echo "API=x" >> "$GITHUB_ENV" Env var for later steps
echo "$HOME/bin" >> "$GITHUB_PATH" Add to PATH for later steps
echo "## Done" >> "$GITHUB_STEP_SUMMARY" Markdown on the run page
${{ hashFiles('**/package-lock.json') }} Cache key from lockfiles
${{ toJSON(github.event) }} Dump the event for debugging

gh CLI

gh run list --workflow ci.yml -L 5 Recent runs of one workflow
gh run watch Follow the current run live
gh run view --log-failed Only the failing step logs
gh run rerun <id> --failed --debug Retry failed jobs with debug logs
gh workflow run deploy.yml -f target=staging Dispatch with inputs
gh pr checks --watch Wait for PR checks to finish