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

Original Article ↗ Hacker News Discussion ↗

GitHub Actions’ reliance on third‑party “actions” without a proper lockfile mechanism is raising alarms about supply‑chain security and build reproducibility, since dependencies can change or be compromised without any modification to a project’s own code. Commenters argue that Microsoft is underinvesting in maintaining core official actions while pushing AI features and ecosystem lock‑in, leaving teams to rely on fragile, opaque YAML workflows and unpinned transitives. Many advocate minimizing dependencies on marketplace actions in favor of plain scripts, containers, or alternative CI/CD systems such as GitLab CI, Buildkite, or self‑hosted tools.

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.