I'll think twice before using GitHub Actions again

Original Article ↗ Hacker News Discussion ↗

Engineers describe running complex CI/CD workflows on GitHub Actions—especially for monorepos—as brittle, opaque, and hard to debug, largely due to YAML-based “pipeline programming,” required-check quirks, and the lack of a first-class way to run workflows locally. Many advocate treating CI systems as thin orchestrators over real scripts or build tools (Bazel, Nx, Dagger, etc.) so the same logic can run on laptops and any CI runner, reducing vendor lock-in and configuration sprawl. Alternatives such as GitLab CI, Buildkite, Azure DevOps, and custom runners are compared, but most agree that complexity and misuse, rather than any single platform, are the root problems.

GitHub Actions and Monorepos

  • Many argue GitHub Actions is a poor fit for complex monorepos and conditional workflows; required status checks don’t play well with jobs that only run when certain paths change.
  • Others counter that the core problem is monorepo complexity, not Actions itself, and suggest using monorepo tools (Bazel, Nx, turborepo, “meta”) plus a thin CI wrapper.
  • Workarounds include “no-op” jobs or a final “all-done” job that inspects upstream job results so required checks can pass even when some jobs are skipped.

YAML, Logic, and “CI as Orchestrator”

  • Strong sentiment that YAML “programming” doesn’t scale. People describe GitHub, GitLab, Azure DevOps, etc. as encouraging Turing-complete behavior in YAML with poor tooling.
  • Popular pattern: keep CI config as a thin orchestrator calling repo-local scripts (deploy.sh, Make/Just/Rake tasks, etc.). All real logic lives in tested scripts that run identically locally and in any CI.
  • Some note that caching, sharding, artifacts, and provider‑specific features inevitably push logic back into CI config.

Local Development and Debugging

  • A major pain point is lack of an official way to run GitHub Actions locally. Third‑party tools (act, others) are seen as helpful but incomplete or behaviorally different from real runners.
  • Many describe “search and deploy” debugging: tiny commits and force‑pushes just to see if YAML changes work.
  • Several vendors (Buildkite, CircleCI, GitLab via gitlab-ci-local, Nix-based setups, Earthly, Dagger) are praised for better local or isomorphic pipelines.

Performance, Reliability, and UX

  • GitHub-hosted runners are often called slow and flaky; jobs sometimes hang or fail randomly and pass on rerun.
  • Others find Actions “good enough” and more productive than older systems (Jenkins, Travis, TeamCity) due to easy setup and marketplace actions.

Security, Secrets, and Vendor Lock‑In

  • Actions’ secret handling and inherited permissions are seen as easy to misuse; role/OIDC-based cloud auth is recommended but underused.
  • Several argue that deep coupling to any one CI (via proprietary DSLs and marketplace plugins) leads to lock‑in; scripts + generic runners are viewed as a safer long‑term architecture.