GitHub Actions has a package manager, and it might be the worst
by robin_reala on 12/8/2025, 8:15:32 AM
https://nesbitt.io/2025/12/06/github-actions-package-manager.html
Comments
by: saagarjha
What’s more, GitHub has basically stopped maintaining their own actions, pushing people to sketchy forks to do basic things. Their entire ecosystem is basically held up with duct tape and gets very little investment.
12/8/2025, 9:08:17 AM
by: baq
Normally I’d say stop kicking the dead horse, but GHA deserves all the complaints it gets and then some. It’s the embodiment of everything that’s bad in ‘less is more’.<p>My biggest concern with it is that it’s somehow the de facto industry standard. You could do so much better with relatively small investments, but MS went full IE6 with it… and now there’s a whole generation of young engineers who don’t know how short their end of the stick actually is since they never get to compare it to anything.
12/8/2025, 9:31:40 AM
by: bloppe
While I hate defending GHA, the docs do include this:<p>- Using the commit SHA of a released action version is the safest for stability and security.<p>- If the action publishes major version tags, you should expect to receive critical fixes and security patches while still retaining compatibility. Note that this behavior is at the discretion of the action's author.<p>So you can basically implement your own lock file, although it doesn't work for transitive deps unless those are specified by SHA as well, which is out of your control. And there is an inherent trade-off in terms of having to keep abreast if critical security fixes and updating your hashes, which might count as a charitable explanation for why using hashes is less prevalent.
12/8/2025, 10:02:31 AM
by: Group_B
I was just writing about how crazy it is to use the third-party ssh tool<p><a href="https://broderic.blog/post/moving-away-from-netlify/" rel="nofollow">https://broderic.blog/post/moving-away-from-netlify/</a>
12/8/2025, 1:19:53 PM
by: amluto
> The researchers identified four fundamental security properties that CI/CD systems need: admittance control, execution control, code control, and access to secrets.<p>Why do CI/CD systems need access to secrets? I would argue need access to APIs and they need privileges to perform specific API calls. But there is absolutely nothing about calling an API that fundamentally requires that the caller know a secret.<p>I would argue that a good CI/CD system should not support secrets as a first-class object at all. Instead steps may have privileges assigned. At most there should be an adapter, secure enclave style, that may hold a secret and give CI/CD steps the ability to do something with that secret, to be used for APIs that don’t support OIDC or some other mechanism to avoid secrets entirely.
12/8/2025, 9:24:34 AM
by: domenkozar
What if GitHub Actions were local-first and built using Nix (proper locking)?<p><a href="https://github.com/cachix/cloud.devenv.sh" rel="nofollow">https://github.com/cachix/cloud.devenv.sh</a>
12/8/2025, 1:19:29 PM
by: pjc50
This is making me feel quietly vindicated in pushing back on migrating our Jenkins/Ansible setup to GHA simply because corporate wanted the new shiny thing. Fortunately the "this will be a lot of work, i.e. cost" argument won.<p>Mind you, CI does always involve a surprising amount of maintenance. Update churn is real. And Macs still are very much more fiddly to treat as "cattle" machines.
12/8/2025, 9:48:59 AM
by: dwroberts
Pleased this is being discussed somewhere as it’s something that has troubled me for a while.<p>There are so many third party actions where the docs or example reference the master branch. A quick malicious push and they can presumably exfiltrate data from a ton of repositories<p>(Even an explicit tag is vulnerable because it can just be moved still, but master branch feels like not even trying)
12/8/2025, 9:12:40 AM
by: bluenose69
I agree 100% with what I think is the key phrase, viz. "the results can change without any modification to your code".<p>I maintain an R package that is quite stable and is widely used. But every month or so, the GHA on one of the R testing machines will report an error. The messages being quite opaque, I typically spend a half hour trying to see if my code is doing something wrong. And then I simply make a calendar item to recheck it each day for a while. Sure enough, the problems always go away after a few days.<p>This might be specific to R, though.
12/8/2025, 10:46:07 AM
by: Raed667
To get something of a lockfile you can use the hash of the version you want to pin your dependencies:<p>> actions/checkout@f43a0e5ff2bd294095638e18286ca9a3d1956744
12/8/2025, 9:37:48 AM
by: pshirshov
Run Nix atop of Actions, minimize the amount of actions you depend on. That works. As a bonus, you now can run your flows locally too.<p>I have a little launcher for that which helps: <a href="https://github.com/7mind/mudyla" rel="nofollow">https://github.com/7mind/mudyla</a>
12/8/2025, 11:38:55 AM
by: worldsayshi
I've not understood the propensity for using yaml for CI pipelines and workflows in general. A decent programming language would be a big improvement.<p>Why not just build the workflows themselves as docker images? I guess running other docker images in the workflow would then become a problem.
12/8/2025, 10:52:19 AM
by: tom1337
We are currently using GitHub Actions for all our CI tasks and I hate it. Yes, the marketplace is nice and there are a lot of utility actions which make life easier, but they all come with the issues the post highlights. Additionally, testing Actions locally is a nightmare. I know that act exists but for us it wasn't working most of the time. Also the whole environment management is kinda odd to me and the fact, that when using an environment (which then allows to access secrets set in that environment) it always creates a new deployment is just annoying [1]<p>I guess the best solution is to just write custom scripts in whatever language one prefers and just call those from the CI runner. Probably missing out on some fancy user interfaces but at least we'd no longer be completely locked into GHA...<p>[1] <a href="https://github.com/orgs/community/discussions/36919" rel="nofollow">https://github.com/orgs/community/discussions/36919</a>
12/8/2025, 10:56:28 AM
by: asmor
See also this excellent video essay by fasterthanlime: GitHub Actions Feels Bad[1].<p>I'm pretty sure it contains the exact line of it being "deeply confused about being a package manager".<p>[1]: <a href="https://www.youtube.com/watch?v=9qljpi5jiMQ" rel="nofollow">https://www.youtube.com/watch?v=9qljpi5jiMQ</a>
12/8/2025, 11:39:53 AM
by: cyberax
Yep. I'm switching our workflows to instead use regular utilities running inside a Docker container.<p>This works well for _most_ things. There are some issues with doing docker-in-docker for volume mapping, but they're mostly trivial. We're using taskfiles to run tasks, so I can just rely on it for that. It also has a built-in support for nice output grouping ( <a href="https://taskfile.dev/docs/reference/schema#output" rel="nofollow">https://taskfile.dev/docs/reference/schema#output</a> ) that Github actions can parse.<p>Pros:<p>1. Ability to run things in parallel.<p>2. Ability to run things _locally_ in a completely identical environment.<p>3. It's actually faster!<p>4. No vendor lock-in. Offramp to github runners and eventually local runners?<p>Cons:<p>It often takes quite a while to understand how actions work when you want to run them in your own environment. For example, how do you get credentials to access the Github Actions cache and then pass them to Docker? Most of documentation just tells: "Use this Github Action and stop worrying your pretty little head about it".
12/8/2025, 9:25:18 AM
by: IshKebab
> The core problem is the lack of a lockfile. Every other package manager figured this out decades ago<p>Well... not Pip!
12/8/2025, 12:48:17 PM
by: ignoramous
> <i>Some teams vendor actions into their own repos. zizmor is excellent at scanning workflows and finding security issues. But these are workarounds for a system that lacks the basics.</i><p>Harsh given GitHub makes it very easy to setup attestations for Artifact (like build & sbom) provenances.<p>That said, Zizmor (static analyser for GitHub Actions) with Step Security's <i>Harden Runner</i> (a runtime analyser) [0] pair nicely, even if the latter is a bit of an involved setup.<p>[0] <a href="https://github.com/step-security/harden-runner" rel="nofollow">https://github.com/step-security/harden-runner</a><p>> <i>The fix is a lockfile.</i><p>Hopefully, SLSA drafts in Hermetic build process as a requirement: <a href="https://slsa.dev/spec/v1.2/future-directions" rel="nofollow">https://slsa.dev/spec/v1.2/future-directions</a>
12/8/2025, 11:12:02 AM
by: LoganDark
I checked out the linked GitHub repo <a href="https://github.com/ecosyste-ms/package-manager-resolvers" rel="nofollow">https://github.com/ecosyste-ms/package-manager-resolvers</a> and it appears to be just a README.md that collects summaries of different package managers? How do I know these weren't just LLM-generated?
12/8/2025, 9:41:40 AM
by: TrianguloY
I'm not sure I follow.<p>If I write actions/setup-python@v1, I'm expecting the action to run with the v1 tag of that repository. If I rerun it, I expect it to run with the v1 tag of that repository...which I'm aware may not be the same if the tag was updated.<p>If I instead use actions/setup-python@27b31702a0e7fc50959f5ad993c78deac1bdfc29 then I'm expecting the action to run with that specific commit. And if I run it again it will run with the same commit.<p>So, whether you choose the tag or the commit depends on whether you trust the repository or not, and if you want automatic updates. The option is there...isn't it?
12/8/2025, 9:40:22 AM