by tomeraberbach
1 subcomments
- Mildly ironic that the quickstart suggests starting with an unpinned action
gjtorikian/gh-actions-lockfile@v1
Presumably since it has to run first it must run unpinned?
- One of the biggest problems with GitHub Actions is that, even with fully transitive locking at the action layer, you still can’t really guarantee hermetic execution: lots of actions do implicit version resolution on tools by default. For example, setup-python, etc. will select a reasonable version based on the constraints you give it, which may end up being the pre-installer runner’s Python, or a newly released patch version, etc.
Fully pinning action references themselves is a step in the right direction, but the ecosystem as a whole probably has expectations that are misaligned with reproducibility/hermeticity, and those expectations will be challenging to overcome.
by supriyo-biswas
2 subcomments
- TBH this discussion and the need for a lockfile for your CI makes me dizzy, is there something I'm missing wrt GHA that makes it awesome enough to be worth these tradeoffs?
For reference, I come from a Gitlab CI background and all I want is to specify a container, and the CI system should clone my repo in it and run some tests; perhaps optionally allow me to write stuff in a text file that can be displayed on the pull request or the commit (although Gitlab CI doesn't do that AFAIK). Is there something I'm missing due to which GHA architecture is so complicated?
- I have trust issues using actions that are not from official and reputable sources like GitHub official and AWS actions. I don’t know why an ssh action is necessary, seems like a nice way to get your ssh credentials stolen and ssh isn’t that hard.
by hanspagel
2 subcomments
- From what I see, this does not help with pinning the dependencies and it doesn’t verify the downloaded action has the same content as it used to have. In other words, this is a tiny patch on a big wound.
We use commit hashes to pin actions, have the version as a comment (e.g # v4) and renovate will keep both up to date in the PRs.
And there is a more or less recently added repository setting to require actions to be pinned to hashes.
by silverwind
2 subcomments
- Pinning actions doesn't really work because most action dependencies are unpinned thanks to npm default behaviour of not pinning them.
by NamlchakKhandro
1 subcomments
- Why do you need this?
Just pin your actions to shasum
by jbergstroem
1 subcomments
- Another (more complete? maintenance, security checks) solution is to allow renovatebot handle this for you. Enable this preset: https://docs.renovatebot.com/presets-helpers/#helperspingith...
..and in the next update cycle, you will see all actions be pinned like this:
- uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6
by oldmancode
0 subcomment
- https://github.com/suzuki-shunsuke/pinact works great
- I have been banging on that drum for like 2 years now, glad the community has figured a way around it. Still utterly ridiculous that this is not native.
They even closed the immutable action issue as a "wont fix" cause you know when it's too hard we all know the best way is to give up. Not like there wasany major security incident this year due to this /s
Hacker News