Run GitHub Actions locally

Local execution appeal and basic workflow

• Many commenters like the idea of running GitHub Actions locally to speed up iteration and avoid “CI ping‑pong.”
• act is generally seen as useful for simple workflows or for checking basic logic before pushing.

Secrets, permissions, and environment configuration

• Handling secrets and environment‑specific variables is a recurring pain point.
• People load secrets from local files or .env files and sometimes inject dummy values for tests.
• Workload identity / OIDC flows (e.g., to AWS) often require special branching (if: ${{ env.ACT }}) or alternate auth paths when running locally.

Platform and runner mismatches

• Apple Silicon vs x86, and different base images, cause many failures that don’t reproduce locally.
• Large “runner-like” images exist but are huge (tens of GB) and can fail with poor error messages when disk is exhausted.
• Some report act never getting beyond dry‑run in real-world setups (e.g., Ruby on M‑series with custom runners).

Act’s emulation limits and missing features

• act doesn’t use the same images or environment as GitHub’s hosted runners; it’s an approximation that diverges in edge cases.
• No macOS support, so iOS/macOS workflows can’t really be debugged.
• Podman support is effectively absent; related issues have been closed or stalled, which frustrates some users.
• Many workflows need if: !env.ACT guards because not everything can be exercised locally.

Debugging strategies: local vs remote

• Several users find it more reliable to debug directly in CI by pausing jobs and SSHing into runners using “ssh action”–style tools.
• Others simply accept remote CI feedback loops or use separate “scratch” repos to spam workflow experiments.

Design patterns to tame CI complexity

• Common advice: keep GitHub Actions YAML thin; move real logic into scripts, containers, or tools (bash, docker-compose, Task, Nix, dagger, pixi, etc.) that run identically locally and in CI.
• Nix‑based setups and similar environment managers are praised for reproducibility and platform‑agnostic local/CI parity.

Broader CI/CD and vendor‑lock discussion

• Some argue GitHub should provide an official local runner; others suspect lock‑in and billed minutes discourage this.
• GitLab, Jenkins, TeamCity, Gitea Actions, and various Nix‑based or code‑based systems are discussed as alternatives, each with its own trade‑offs.
• Several commenters express broader frustration that CI/CD remains fragile, proprietary, YAML‑heavy, and hard to debug compared to just running scripts.