- 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.