GitHub Actions Are a Problem

Original Article ↗ Hacker News Discussion ↗

Many developers praise GitHub Actions for free, convenient CI/CD across multiple platforms, but increasingly criticize it for opaque workflows, slow feedback loops, YAML complexity, and vendor lock-in. Commenters argue that core build and deploy logic should live in regular scripts that can be run locally or on any CI system, with Actions used only as thin orchestration. A range of alternatives and workarounds are mentioned — from tools like Dagger, Earthly, Garden, and `act` to self-hosted runners and generic workflow engines — all aiming to regain portability, testability, and control over pipelines.

Perceived Problems with GitHub Actions

  • YAML workflows become complex, hard to debug, and not easily testable locally.
  • Strong reliance on third‑party actions makes behavior opaque and increases vendor lock‑in.
  • Terminology is confusing (actions vs workflows), and the runner implementation is seen as convoluted, with reports of odd behaviors and exit codes.
  • Feedback loop is slow: needing commits and remote runs to iterate on pipeline logic is widely disliked.
  • Some consider Actions “good enough” but inferior in conceptual clarity to simpler systems like GitLab CI.

Workarounds and Recommended Practices

  • Keep YAML “thin”: use it mainly for triggers and orchestration; put real logic into scripts, Make/just targets, Magefiles, Bazel, etc.
  • Ensure all CI steps can run locally with the same commands used by CI.
  • Prefer local scripts and containers over heavy reusable actions; some avoid all but basic setup actions.
  • Use Docker images or devcontainer images as the canonical environment for both local and CI runs.
  • Centralize common logic via shared scripts or DSLs that compile to CI YAML; treat CI as a glue layer.

Local Execution and Tooling Gaps

  • Strong demand for a first‑party way to run GHA locally; current self‑hosted runners still require commits and remote execution.
  • act and related emulators help some workflows but are described as incomplete, brittle, and hard to debug for complex pipelines.
  • Reverse‑shell/debug actions (e.g., tmate) are praised for troubleshooting on actual runners.

Vendor Lock‑in and Platform Concerns

  • Actions’ ecosystem and free/cheap hosted runners (especially for Windows/macOS) are seen as a powerful lock‑in mechanism.
  • Some argue GitHub’s CI monetization disincentivizes fully local, free runners.
  • Others emphasize GitHub’s broader feature set and network effects as the primary “stickiness.”

Alternative CI/Workflow Approaches

  • Multiple projects aim at CI‑agnostic or “pipelines as code” solutions (Dagger, Earthly, Garden, Windmill, Cirrus CLI, Cicada).
  • Jenkins’ Groovy DSL and shared libraries are cited as a better abstraction model than raw YAML.
  • Attempts to build universal workflow/CI engines face leaking abstractions, environment variance, and high migration costs.

Broader Reflections on CI/CD Complexity

  • Many see CI pipelines as overcomplicated workflow engines repeatedly reinvented.
  • There is agreement that deployments should be auditable, scriptable, and not entirely tied to a single CI provider.