GitHub Actions CI/CD from push to deploy

A workflow starts on events. For CI/CD the usual set is three: push to the default branch builds, tests and deploys; pull_request builds and tests every proposed change; and workflow_dispatch adds a Run workflow button for a manual redeploy.

Two settings keep the pipeline fast from the first commit. A path filter such as paths-ignore on push skips the build and deploy for commits to main that touch only Markdown or docs, and when a trigger sets both branch and path filters, GitHub runs the workflow only when both match. A concurrency group keyed on the branch, with cancel-in-progress set for pull requests, cancels the run a newer push supersedes, so runners spend their minutes on the latest commit.

The pull_request trigger runs on every change, so build and test report on every pull request and work as required status checks. To skip expensive jobs on docs-only pull requests too, the path filter guide gates them with a job-level if: that keeps required checks reporting.

Jobs in a workflow run in parallel by default, so a build job and a test job finish in the time of the longer one. Declare job dependencies with needs only where they are real: the deploy job needs both, and nothing else waits.

The build job uploads its output as an artifact, and the deploy job downloads it, so production receives the exact files built from the tested commit.

When the test job is the long pole, shard it. A matrix runs one copy of the job per shard, and each copy hands its index to the test runner's --shard flag, which Vitest, Jest and Playwright all accept.

Give every job a timeout with timeout-minutes. GitHub's default is 360 minutes; a 15 or 20 minute bound ends a hung job quickly and frees its runner for the next one.

Dependency installs are the step a cache speeds up most. The setup actions for Node.js, Python, Java, Go, Ruby and .NET carry built-in caching: cache: pnpm on actions/setup-node restores the pnpm store keyed on pnpm-lock.yaml, so the cache refreshes when dependencies change and restores on every other run.

For other paths, such as build output or a compiler cache, actions/cache takes a path and a key you build with hashFiles(). Each repository gets 10 GB of cache storage by default, and GitHub removes entries nobody has read in seven days.

An environment is where deployment rules live. Add environment: production to the deploy job, then configure the environment under the repository's settings.

Required reviewers pause the job until one of up to six listed people or teams approves it. A wait timer holds it for a set number of minutes. Deployment branch rules let main, or branches matching a pattern you choose, deploy to the environment.

Environment secrets reach only jobs that reference the environment, and only after its protection rules pass, so the production credential stays with the approved deploy job.

Store credentials as secrets: repository secrets for the whole pipeline, environment secrets for one environment. Secrets reach the runs triggered from your own repository, and a pull request run from a fork receives the GITHUB_TOKEN with read-only permissions.

For cloud deploys, OpenID Connect replaces the stored key. Grant the deploy job id-token: write, configure your cloud account to trust GitHub's OIDC provider, and the job exchanges a token GitHub issues for each run for a short-lived cloud credential scoped to that run.

Keep the workflow's default permissions at contents: read and grant id-token: write on the deploy job alone. That permission lets a job request and use an OIDC token, and the job's repository access stays at contents: read.

Pin every third-party action to a full-length commit SHA, which GitHub's security guidance calls the only way to use an action as an immutable release, and keep the version tag as a trailing comment.

To check a repository's workflows against these settings, run the free /ci-secure skill: it reports the attack paths an outsider can walk end to end, including fork code run with privileges and cache poisoning.

Once the pipeline runs, speed comes from two places: less work per run, and faster hardware for the work that remains.

Less work: profile a run, find the stage that owns the most wall-clock time, and apply its fix from the GitHub Actions CI best-practices catalog. Build only affected projects in a monorepo, cut queue time when jobs wait to start, and right-size runners job by job. The fast GitHub Actions guide walks through the whole order of operations.

Faster hardware: StarSling runners are drop-in Ubuntu runners for GitHub Actions. Change runs-on: ubuntu-latest to a StarSling runner label such as starsling-ubuntu-24.04 on the build and test jobs, and the same workflow runs on faster machines with its triggers, environments and secrets as they are.

StarSling agents keep the pipeline improving after the swap. On paid plans they analyze your workflows, run logs and machine telemetry, then open pull requests with the fixes this guide teaches: caching, test sharding, parallel jobs and workflow structure. You review and merge each one.

Every GitHub Actions behavior on this page is from GitHub's own documentation: