- They only lock normal action calls. If your workflows invoke other reusable workflows, you need to keep those hash-pinned manually for now.
- Composite actions are not themselves locked. Instead, they get locked transitively through their callsites i.e. the workflows that call them. This makes any individual caller that uses lockfiles safe, but it also makes the current `gh actions-lock` default unsafe (since it removes hash-pins from the composite action itself, meaning that any external caller that invokes the action loses their transitive pinning).
- Other forms of `uses:` clauses, like Docker images, are also not currently locked via the lockfile. And the same for forms of interior mutability (like an action running `npx ...` under the hood, although the latter is fully outside of GitHub's control to prevent. But these mean that you can't assume that a fully locked Actions setup is in fact 100% immutable.
I hope they address these gaps soon, because it's otherwise an excellent (and long-awaited) feature.
IMO Github should make Immutable tags mandatory to publish on https://github.com/marketplace
(The previous way to provide general actions immutability, i.e. hash-pinning, had this issue and thus required additional checks.)
As the consumer of an action that becomes really hard to find out unless I take the whole codebase apart.
You don’t have to go Jenkins, it’s just that GitHub Actions are uniquely bad and I would avoid them.
If you are relying on the free version of GitHub actions for small projects, I would consider just running something on a NUC or Pi at home.
It feels like, I don’t know. You go to somebody’s house and they have one plate, one cup, one spork. They’re living in a 30th floor walk-up, but one of the windows is missing so there’s a giant hole in the wall.
That’s kind of the subjective experience I get when I see people using GitHub actions.
Same for Windows.
I may be a little old-school about this. That’s fine. I think most people out there who are trying to support multiple platforms with their code should be going one of three directions—(1) some kind of web app, (2) an open-source tool where end-users compile it or run it in their Python interpreter or Node.js or whatever, or (3) a pre-built binary for systems they personally run at home.
I also am not writing out, like, an essay on how to replace GitHub actions for every possible use case that people have GitHub actions for. I am just providing some suggestions for one possible direction. If you get off GitHub actions, you are going to end up with something that is missing some of the features that GitHub actions, maybe some features that you like. The same is true in the reverse—if you switch to GitHub actions, you will obviously lose features that were present in whatever other system you had before. GitHub actions is, after all, completely terrible and switching to it would just be a kind of disaster in a bunch of different ways.
I don’t like to put this kind of wall-of-text disclaimer in comments on HN, and hopefully y’all can figure this stuff out without the wall-of-text disclaimer. It would be kind of… absurd… perhaps, to expect some random commentator on Hacker News to give you exactly the answer that satisfies your needs, unless you put those needs in a question.
Instead I limited myself to two suggestions. If you don’t like them, then figure something else out yourself. You will not have trouble making something better than GitHub actions.
Apple seem to believe this extremely strongly and keep finding new ways to prevent you doing it.
I basically agree, and at work we have a Jenkins master + cluster of build machines. But this does incur substantial sysadmin overhead even if we're using Ansible and all the Windows ones are VMs. (Mac, again, hates being either virtualized or stuck in a rack, and will occasionally insist on someone using the physical display and keyboard on the actual machine to perform updates)
And yes, you should have a Mac for local testing of you target OSX, but it's still useful to have an easy way to run a matrix of platforms in CI.
Jenkins is fine but hard to call it better than GH actions, subjectively.
(I simply put a comment with the upstream URL in my repo in case I want to update in the future.)
For those things an action helps.
But with a lockfile, direct and indirect dependencies both get pinned. (I presume, and haven’t checked yet, but otherwise this feature would be useless)
Use the gh actions-lock extension for the GitHub CLI to generate .github/workflows/actions.lock for actions and their transitive dependencies.
The old way of just writing this in a comment on the same line seems fine to me -- intuitive and much more concise.
> if the maintainer is using real SemVer, it's easier to upgrade
Could you elaborate on this? I didn't see how yet.
Personally I found the risk of running someone else’s GitHub Action in my repo to not be worth it. Even GitHub’s own Action to checkout repos is way more complex than I need it to be and last I checked had dependencies which could be targeted. I opt instead to not run any third-party Actions (not even GitHub’s official ones) in my repos.
This is a new first-party feature by Github to allow locking of transitive dependencies.
Your snark is unwarranted, though, since the crux of the comment is not using any Action you haven’t built. Lockfiles don’t solve the complexity and trust problem.
> Lockfiles don’t solve the complexity and trust problem.
They don't solve it on their own, but they are an important building block, and allow GHA to take the same shape that other package ecosystems have (e.g. npm, Cargo), where trust issues can be worked around to some degree with a combination of consumption-delay + automated security review. Of course, going with a smaller surface area is always preferrable.
Fair. I know what it’s like to be frustrated with a general trend, and unfortunately we have to pick one comment to reply to.
> They don't solve it on their own, but they are an important building block
Agreed, it is a good step and I understand why people would want to do it. But I also stand by saying “not a trade-off I want to make (but you do you)”. I mean it in every sense: I still don’t want to do it for myself, but in no way am I claiming my preference is right for everyone.
As I see it, TFA's only value is that link to a better article.
Lack of transitive pinning support was the biggest supply-chain security criticism against GHA and I'm glad they are finally tackling it!
So some of the extra steps are meaningful. Though I am still not convinced they could not have been implemented in a deliberately backwards-incompatible way to Github action in general, keeping the syntax and removing only the special case that is never both intentional and non-malicious at the same time.
They don't because they don't.
Anybody who's ever moved a git tag knows the ergonomics of doing so are so awful that you're obviously not supposed to be doing it.
/s
This is a step in the right direction, but it’s not even close to a complete solution. And what am I doing installing a plugin to use this? It should just be part of GH, so I can install that and not have yet another source of dependency management to lock down.
I endose this article.