GitHub Actions has a package manager, and it might be the worst

Original Article ↗ Hacker News Discussion ↗

Maintenance and Strategic Direction

  • Multiple commenters report core GitHub-maintained actions (e.g., checkout, cache, setup-*) being archived or closed to contributions, despite being central to most workflows.
  • A quoted GitHub note says resources are being redirected to “other areas of Actions,” which many interpret as deprioritizing maintenance in favor of AI/LLM efforts and Azure migration.
  • Some argue this isn’t exactly “dropping support” but refusing external contributions and only making internal, roadmap-driven changes.

Security, Package-Manager Behavior, and Lockfiles

  • Strong agreement that Actions behaves like a package manager without lockfiles: action versions can change under stable-looking tags or branches, so pipelines can break or be compromised without repo changes.
  • Pinning to SHAs is recommended in docs but:
    • Does not lock transitive dependencies.
    • Is often ignored in practice (most users pin to tags like v1).
    • Can still break when runners or APIs change.
  • Examples of insecure practices: actions referencing master branches, unpinned scripts or binaries from external URLs.
  • Some use scanners (e.g., Zizmor) and hardening actions, or vendor actions into their own repos, but these are seen as fragile workarounds.

Secrets and CI/CD Threat Model

  • Long subthread debates whether CI/CD should handle secrets at all:
    • One side: runners should get capabilities (OIDC, role assumption, secure enclaves) instead of raw secrets.
    • Others: in practice, deployments, signing, cross-cloud testing, license servers, etc. still require secret-like material; CI must manage it securely.
  • GitHub’s OIDC integration with clouds is praised as one of the few well-executed security features, but still seen as “secrets all the way down.”

Alternatives, Runners, and Vendor Lock-in

  • Suggestions: GitLab CI, CircleCI, Jenkins, Buildkite, TeamCity, Forgejo, Onedev, Woodpecker/Drone, ArgoCD; opinions are mixed, many say none are “actually good.”
  • Third-party runners (Depot, Blacksmith) are praised as faster/cheaper than GitHub-hosted runners while keeping GitHub as UI/trigger.
  • Some highlight “trusted publishing” flows (PyPI, npm) as effectively tying major ecosystems to GitHub/GitLab CI and limiting competition.

Workflow Design, YAML, and Local-First Approaches

  • Several argue most marketplace actions are unnecessary wrappers; prefer Makefiles, shell scripts, or custom Docker images invoked from CI so they run identically locally.
  • Frustration with YAML-based pipelines and lack of first-class local execution; tools like Nix, Dagger, mise, Taskfile, and act are mentioned as ways to regain determinism and local parity.
  • Overall sentiment: Actions is convenient “free compute” tightly integrated with GitHub, but brittle, opaque, and under-maintained.