GitHub Actions Vocabulary: CI/CD Terms for Developers

GitHub Actions is the built-in CI/CD platform for GitHub repositories. It automates everything from running tests on pull requests to deploying to production. Whether you are writing your first workflow or reviewing a colleague’s pipeline, this vocabulary guide will help you understand and discuss GitHub Actions confidently.

The Core Structure

Workflow

A workflow is an automated process defined in a YAML file in .github/workflows/. A repository can have multiple workflows — for example, one for CI on pull requests and one for deployment on merge to main.

“The deployment workflow is failing — let’s check the Actions tab."
"I’ll add a new workflow that runs the linter on every PR.”

Trigger (on:)

The on: key defines what events trigger a workflow. Common triggers include push, pull_request, schedule (cron), workflow_dispatch (manual), and release.

“The workflow is triggered on push to main and on pull_request targeting main."
"Add a workflow_dispatch trigger so we can run the deployment manually when needed.”

Job

A job is a set of steps that run on the same runner. Jobs in a workflow run in parallel by default, but you can make them sequential with needs:.

“Split the build and deploy into separate jobs — deploy should only run if build succeeds."
"The test job takes 8 minutes. Let’s split it into a matrix so different test suites run in parallel.”

Step

A step is a single task within a job. Steps run sequentially on the same runner. A step can either run a shell command (run:) or use a pre-built action (uses:).

“The step is failing because the Node version is wrong — add a setup-node step before it.”

Action

An action is a reusable unit of automation. GitHub provides official actions (e.g., actions/checkout, actions/setup-node), and thousands of community actions are available on the GitHub Marketplace.

“Use the official actions/checkout action to clone the repo in your workflow."
"There’s a community action for deploying to S3 — no need to write the shell script yourself.”

Runners and Environments

Runner

A runner is the server that executes a job. GitHub provides hosted runners (Ubuntu, Windows, macOS). You can also use self-hosted runners on your own infrastructure.

“The job runs on ubuntu-latest by default — specify a fixed version like ubuntu-24.04 for reproducibility.”

Self-Hosted Runner

A self-hosted runner is a machine you manage yourself, registered with GitHub to run workflows. Useful when you need specific hardware, more power, or access to private network resources.

“We use a self-hosted runner for the iOS build because it needs a macOS machine with Xcode."
"Make sure the self-hosted runner is ephemeral — don’t let state persist between runs.”

Environment

An environment in GitHub Actions defines deployment targets (e.g., staging, production). Environments can have protection rules — required reviewers, wait timers — before a deployment job proceeds.

“The production environment requires approval from two reviewers before the deploy job runs."
"Secrets scoped to an environment are only available to jobs that target that environment.”

Data, Secrets, and Outputs

Secret

A secret is an encrypted value stored in GitHub and injected into workflows as an environment variable. Secrets are masked in logs.

“Store the API key as a repository secret and reference it in the workflow as ${{ secrets.API_KEY }}."
"Never hardcode credentials in the workflow file — always use secrets.”

Artifact

An artifact is a file or directory produced by a workflow that you want to persist or share between jobs. Use actions/upload-artifact to save and actions/download-artifact to retrieve.

“Upload the build output as an artifact so the deploy job can download it without rebuilding."
"Store the test report as an artifact so we can inspect it after the run.”

GITHUB_TOKEN

GITHUB_TOKEN is an automatically generated token available in every workflow. It has permissions to interact with the repository — creating releases, posting PR comments, pushing packages — without needing a personal access token.

“Use ${{ secrets.GITHUB_TOKEN }} to authenticate the action — no need to create a PAT."
"Limit the GITHUB_TOKEN permissions to only what the workflow needs: contents: read, packages: write.”

Advanced Features

Matrix Strategy

A matrix lets you run a job multiple times with different variable combinations — for example, testing against multiple Node versions or operating systems simultaneously.

“We use a matrix to run the tests on Node 18, 20, and 22 in parallel."
"Add os: [ubuntu-latest, windows-latest] to the matrix to catch platform-specific bugs.”

Concurrency

The concurrency: key ensures that only one run of a workflow (or a concurrency group) is active at a time. Useful for deployments where you don’t want two deploys running simultaneously.

“Set concurrency on the deploy workflow with cancel-in-progress: true so a new push cancels the previous deploy.”

if Condition

The if: condition on a job or step controls whether it runs. You can use expressions based on event data, job status, or any context variable.

“Add if: github.ref == 'refs/heads/main' so the deploy step only runs on the main branch."
"Use if: failure() to run the notification step even when the previous step fails.”

Cache

The actions/cache action stores and restores files between runs — typically node_modules, build caches, or downloaded dependencies. It dramatically speeds up workflows.

“Cache the node_modules directory using the package-lock.json as the cache key."
"The cache is stale — the key changed when we updated a dependency.”

Reusable Workflow

A reusable workflow is a workflow that can be called from another workflow using workflow_call. It promotes DRY (Don’t Repeat Yourself) principles across multiple repositories.

“We extracted the build and test logic into a reusable workflow in the shared platform-ci repo."
"Any team can call the shared deploy workflow and pass in their environment-specific inputs.”

Composite Action

A composite action combines multiple steps into a single action, packaged as a reusable unit within your repository. Unlike a reusable workflow, a composite action runs within the calling job.

“We created a composite action that sets up Node, installs dependencies, and runs lint — one uses: call instead of three steps.”

OIDC (OpenID Connect)

OIDC allows GitHub Actions to request short-lived credentials from cloud providers (AWS, Azure, GCP) without storing long-lived secrets. The runner authenticates using a JWT token that the cloud provider verifies.

“We switched from static AWS access keys to OIDC — the workflow gets temporary credentials automatically."
"With OIDC, there are no long-lived secrets to rotate or accidentally expose.”

How to Use This in Conversation

In PR review:

“The workflow runs on every push to every branch — add a paths: filter so it only triggers when relevant files change.”

In planning:

“Let’s use a matrix build to run the integration tests against both Postgres 15 and 16 so we don’t get surprised by a version upgrade.”

In debugging:

“The deploy job is being skipped — check the if: condition. It’s probably evaluating to false because github.ref doesn’t match.”

When setting up a new project:

“First add the GITHUB_TOKEN permissions block to the workflow — the default is too permissive. Then add the OIDC trust policy on the AWS side.”

GitHub Actions vocabulary is essential for any developer who wants to own their CI/CD pipeline, contribute to workflow improvements, or simply understand why the green tick appeared (or didn’t) on their PR.