The Pain That Is GitHub Actions

Original Article ↗ Hacker News Discussion ↗

Overall Sentiment Toward GitHub Actions

  • Many find Actions powerful and tightly integrated with GitHub but also opaque, brittle, and under-documented.
  • Common complaints: confusing permission model, surprising defaults, flaky behavior, and a feeling the product is stagnating or understaffed.
  • Several people still say it’s the “least bad” mainstream CI, especially compared to older Azure DevOps pipelines or Jenkins Groovy jobs.
  • Others describe it as something you only use because you’re forced to or because “it comes with GitHub.”

Comparisons with Other CI Systems

  • GitLab CI is frequently preferred: simpler mental model (“run scripts in containers”), better runners, and more coherent UX, though it has its own sharp edges.
  • Jenkins is praised for flexibility and longevity (years‑uptime instances), but widely disliked for plugins, security, and Groovy pipelines.
  • Azure DevOps pipelines are described as equally painful or worse, with poor docs and no good local runner.
  • Drone, Woodpecker, CircleCI, Buildkite, Concourse, Bitbucket Pipelines and sourcehut are cited as nicer in specific ways (SSH into jobs, simpler models), but none emerges as a universal winner.

YAML, UX, and Documentation

  • Strong backlash against YAML as an execution language: hard to debug, no real tooling, whitespace gotchas, and Turing-complete config “programs” with poor visibility.
  • Some defend YAML as fine for a thin orchestration layer, provided real logic lives in scripts or code.
  • Several people generate workflow YAML from higher‑level languages (Nix, CUE, RCL, Pkl, Kotlin DSL) to avoid repetition and add structure.
  • The Actions UI is criticized as clunky; docs are seen as product‑oriented rather than explaining core concepts and behavior.

Security, Permissions, and Supply-Chain Risks

  • Many argue the default GITHUB_TOKEN permissions should be zero; the current mix of org, repo, workflow, and job permissions is seen as confusing and unsafe.
  • Shared third‑party actions are viewed as a major supply‑chain risk; a recent action compromise reinforced this.
  • Pinning actions by hash is recommended, but people note it’s rare in practice and doesn’t protect against a dependency of an action being hijacked.
  • Tools like Dependabot/Renovate help update pinned hashes, but still require human review. There’s debate over pinning (security) vs rolling updates (operational smoothness).
  • Traps: workflows can’t trigger other workflows when using GITHUB_TOKEN, pushing from Actions often needs PATs or machine accounts, and cron workflows can be tied to departed users.

Local-First Philosophy and Minimizing CI Logic

  • A strong theme: treat CI as a dumb orchestrator. Put real logic in scripts, Makefiles, CLIs, Nix/Bazel/Dagger configs, or language-specific tools; have CI just “run this command.”
  • Benefits: same commands work locally and in CI, easier debugging, reduced vendor lock‑in, and simpler migrations.
  • Several teams run almost everything via a single “one-click build” script (or Nix flake, Bazel target, Dagger pipeline) and call that from Actions.
  • Tools like act, gitlab-ci-local, and sourcehut’s SSH access are praised for shortening the “commit and pray” loop, though they don’t cover all enterprise setups.

Performance, Caching, and Cost

  • Complaints about slow startup, especially on shared or Kubernetes-based runners, and about Actions killing jobs with SIGKILL instead of SIGTERM (breaking tools like Terraform).
  • The cache system (10GB per repo, LRU behavior) is described as limited, slow, and sometimes unreliable; container jobs have awkward permissions and caching semantics.
  • Pricing is criticized: billing by started minute per job (not actual runtime) drives up costs at scale and encourages anti‑patterns.
  • Many switch to self‑hosted or third‑party high‑performance runners (on bare metal, NVMe, specialized services) for big gains in speed and predictable caching.

Alternatives, Ecosystem, and VC-Backed Tools

  • Earthly’s near‑halted development and Dagger’s visible pivot toward AI “agent workflows” fuel skepticism about relying on VC‑backed CI tools.
  • Some still like Dagger as “CI as code in containers,” especially for local–CI parity; others worry the AI push will dilute focus.
  • Nix and Bazel are repeatedly called out as strong foundations for reproducible, local‑first workflows that CI can simply invoke.
  • Overall, the consensus is that CI as a category is inherently hard; GitHub Actions is widely used, but many teams deliberately constrain their use of it to avoid its rough edges.