CI runner
The machine or worker that picks up a CI job and runs its commands. Your workflow is the recipe; the runner is the kitchen.
What it is
A CI runner is the worker that picks up one pipeline job and executes its steps. It may be a fresh virtual machine supplied by GitHub Actions, a container started by GitLab Runner, or a process on hardware your team owns. The workflow describes the job; the runner supplies the operating system, CPU, filesystem, network, and installed tools that make it real.
Runner choice matters when a job needs a particular OS, more memory, a GPU, access to a private network, or simply more parallel capacity. A job waiting in the queue often means no matching runner is free, not that the pipeline itself is slow.
Gotcha: jobs do not inherit your laptop. Pin runtime versions and install every dependency the job needs. Also remember that a runner executes repo code while holding whatever credentials the job receives, so keep permissions narrow and never send secrets to untrusted pull request code.
Ask AI for it
Configure this GitHub Actions workflow to run on ubuntu-latest with an explicit Node version through actions/setup-node, a lockfile-exact install (npm ci, or pnpm install --frozen-lockfile), timeout-minutes: 15, and permissions: contents: read. Split lint, typecheck, test, and build into separate jobs so GitHub can assign them to runners in parallel. Print only the tool versions needed for diagnosis, cache the package manager store by lockfile hash, and do not expose repository secrets to workflows triggered by forked pull requests.