I hate GitHub Actions with passion

Original Article ↗ Hacker News Discussion ↗

Core Pain: Slow, Opaque Feedback Loop

  • Main frustration is the “edit → commit → push → wait” cycle for even trivial workflow fixes, especially when failures occur only on specific OS/arch runners (notably macOS and ARM).
  • Lack of first‑class “SSH into failed runner” support makes debugging painful; you’re forced to guess via logs and repeated runs.
  • Several commenters think the blog post over-attributes a dependency/install problem to Actions itself, but still agree the debugging story is bad.

Local Scripts vs YAML Logic

  • Very strong consensus: do not embed real logic in GitHub Actions YAML.
  • Common pattern: workflow should just:
    1. Check out code
    2. Call a repo‑local script / Makefile / task runner
  • This preserves local debuggability, reduces lock‑in, and makes migration to another CI or local runners easier.
  • Some note this isn’t unique to GHA: any CI becomes painful if logic lives in the CI config rather than scripts.

Tooling for Local/Interactive Runs

  • act is frequently suggested as a local runner; people find it helpful but:
    • Not a full drop‑in, Linux-only for proper runner emulation, and struggles with complex workflows and macOS use cases.
  • SSH-style debugging actions (tmate, now upterm; custom SSH/cloudflared actions) partially address the pain by allowing live shell access to a failing job.
  • Other CIs (SourceHut, Semaphore, some self-hosted setups) are praised for “rebuild with SSH” capabilities.

Environment, Caching, and Reproducibility

  • Installing tools inside Actions is a recurring source of flakiness and time waste.
  • Patterns to mitigate:
    • Use containers or Nix/mise to define reproducible dev/CI environments; let Actions only orchestrate.
    • Use hash-based caching keyed on lockfiles; rely on actions/cache or similar.
    • Some build custom images or run everything inside a single container/VM they can also run locally.

Language & Scripting Debates

  • Disagreement over best scripting layer:
    • Some argue bash + Make/task runners are sufficient “plumbing.”
    • Others highlight bash’s fragility and prefer Python, PowerShell, Deno/TypeScript, or other higher-level tools for anything non-trivial.
  • General agreement that whatever is used must be runnable locally and cross-platform where possible.

GitHub Actions vs Alternatives & Responsibility

  • Mixed views: many dislike GHA UX and see strong vendor lock‑in; others find it still better than Jenkins/Travis and invaluable for free OSS compute and broad OS/arch coverage.
  • Alternatives mentioned: GitLab CI, Bitbucket Pipelines, SourceHut, OneDev, self-hosted Forgejo/Gitea, plus newer platforms (Dagger, RWX, Depot).
  • Some call the blog’s scenario a “skill issue” (misusing Actions for dependency installation), while others stress that the lack of tight feedback loops and interactive debugging is a genuine systemic flaw.