I'll think twice before using GitHub Actions again

Original Article ↗ Hacker News Discussion ↗

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.