# Glossary — CI/CD & Delivery

The canonical vocabulary for this course. Opinionated and repo-flavoured. Once a term is
defined here, every lesson uses it this way. Terms marked *(Part N)* are taught in that part.
Repo-specific values are confirmed in [repo-cicd-map.md](./repo-cicd-map.md).

---

### CI — Continuous Integration
The practice of merging code frequently and **automatically building + testing** every change,
so integration problems surface early. *Repo: every PR runs lint + unit tests + codegen drift
checks + build.*

### CD — Continuous Delivery / Deployment
**Delivery** = every change that passes CI is *ready* to release (a human clicks deploy).
**Deployment** = it releases *automatically*. The line between them is the manual gate. *Repo:
mixed — a scheduled cron auto-deploys the latest release tag to **staging** (delivery→deployment),
but **prod** deploys are manual `workflow_dispatch`. A merge does NOT deploy directly.*

### Pipeline
The automated sequence a change flows through: build → test → (package) → deploy. In GitHub
Actions this is expressed as workflows and jobs.

### Push-based delivery *(Lesson 8)*
CI/CD *pushes* changes to the cluster (runs `helm upgrade`/`skaffold run` from a workflow), as
opposed to a **GitOps** controller (Argo/Flux) that *pulls* desired state from git and
reconciles continuously. *Repo: push-based (not GitOps) — the cluster changes only when a deploy
runs.*

### GitHub Actions *(Lesson 2)*
GitHub's built-in CI/CD system. Workflows (YAML in `.github/workflows/`) run on events, made of
jobs, made of steps, run on runners.

### Workflow *(Lesson 2)*
A YAML file in `.github/workflows/` that runs on a trigger. Has `on:` (events), `jobs:`, and
optional `concurrency`/`permissions`/`env`.

### Event / trigger *(Lesson 2)*
What starts a workflow: `push`, `pull_request`, `workflow_dispatch` (manual), `schedule` (cron),
`workflow_call` (invoked by another workflow), `repository_dispatch`.

### Job *(Lesson 2)*
A unit of a workflow that runs on one runner. Jobs run in parallel by default; use `needs:` to
sequence them. Each job is a fresh machine.

### Step *(Lesson 2)*
An item in a job: either a shell command (`run:`) or an action (`uses:`). Steps in a job share
the runner and run in order.

### Action *(Lesson 2, 4)*
A reusable unit invoked by a step's `uses:`. Types: **JavaScript**, **Docker**, or
**composite** (bundled steps). Marketplace or local (`.github/actions/…`).

### Runner *(Lesson 2, 7)*
The machine that executes a job. **GitHub-hosted** (ephemeral, managed) or **self-hosted** (you
run it). Selected with `runs-on:`. *Repo: self-hosted via ARC.*

### Self-hosted runner / ARC *(Lesson 7)*
A runner you operate. **Actions Runner Controller (ARC)** runs runners as Kubernetes pods
(runner scale sets) that autoscale with the job queue. *Repo: ARC on the platform cluster.*

### Reusable workflow *(Lesson 4)*
A whole workflow that another workflow calls with `uses:` + `with:`/`secrets:` (needs
`on: workflow_call`). Reuse when the thing is shaped like a **pipeline** (multiple jobs, gates,
secrets). *Repo: NOT used — this repo composes via composite actions + `repository_dispatch`
(one workflow triggers another by event), not `workflow_call`.*

### Composite action *(Lesson 4)*
A reusable **sequence of steps** packaged as an action (`.github/actions/…/action.yml`, `using:
composite`). Reuse when the thing is shaped like a **step**. *Repo: ~80 of them.*

### Matrix *(Lesson 12)*
`strategy.matrix` fans one job out over combinations (e.g. multiple services/envs) — parallelism
from a compact spec.

### Concurrency *(Lesson 12)*
`concurrency:` groups runs so a new run cancels/queues an in-flight one for the same key (e.g.
per branch) — avoids racing deploys.

### Path filter *(Lesson 12)*
`on.push.paths` (or path-filtering logic) so a workflow runs only when relevant files change —
essential in a monorepo to avoid building everything on every commit.

### Trunk-based development *(Lesson 6)*
A branching model where everyone commits to one shared branch (**trunk**) in small, frequent
changes behind short-lived branches — the model CI/CD is built for. *Repo: the `tbd.*` workflows
= trunk-based deploy.*

### Environment (GitHub) *(Lesson 6)*
A named deploy target (`environment:`) that can carry **protection rules** — required reviewers,
wait timers, branch limits — and scoped secrets. The place manual approval gates live.

### Artifact registry *(Lesson 5)*
Where built images are stored. *Repo: `asia.gcr.io/student-coach-e1e95` (Google Container/
Artifact Registry).*

### Image tag *(Lesson 5)*
The version label on a built image (often the git SHA or a `TAG`), stamped into the manifests at
deploy (Helm `global.image.tag`, Course 3).

### Skaffold (in CI) *(Lessons 5, 8)*
The deploy tool from Courses 1/3. *Repo: the backend **image** is built by **docker buildx**
(not `skaffold build`); the **deploy** step is `skaffold deploy -f skaffold.backend.yaml`
(= `helm upgrade --install`).*

### OIDC / Workload Identity Federation *(Lesson 9)*
Keyless auth: GitHub mints a short-lived **OIDC token** for a job (`id-token: write`); GCP's STS
exchanges it for a short-lived Google credential — no static service-account keys. *Repo: via
`google-github-actions/auth`.*

### Binary Authorization *(Lesson 10)*
A GCP admission control that only lets images with valid **attestations** run on GKE — a
supply-chain gate. *Attestation = a cryptographic signature that an image passed a required step.
Repo: attestations ARE created (`gcloud … binauthz attestations sign-and-create`), but the policy
is `DRYRUN_AUDIT_LOG_ONLY` — audited, not yet blocking.*

### Attestation *(Lesson 10)*
A signed statement (e.g. via **cosign**/an attestor) that an image met a policy (built by the
trusted pipeline, scanned, etc.), verified at deploy by the public key.

### SLSA *(Lesson 10)*
Supply-chain Levels for Software Artifacts — a framework grading how tamper-resistant a build/
provenance chain is.

### Drift guard (`ensure-make-*`) *(Lessons 3, 11)*
A CI check that regenerates generated code and fails on `git diff` — keeps committed generated
artifacts in sync. *Repo: `.github/scripts/ensure-make-generate-dags.bash`,
`ensure-make-gen-db-schema.bash`.*

### BDD / E2E in CI *(Lesson 11)*
Integration tests run against a real stack in CI (a kind cluster + Skaffold deploy + `run.bash
bdd` inside gandalf, Course 1). Slower, higher-fidelity than unit tests.