21–28 of 28 posts
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
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…
Earlier quoted context omitted.
If that action itself has unpinned dependencies that doesn't accomplish much.
Don't use such actions. Or fork them and commit add the lockfile yourself, if you're cool with the implied maintenance.
Depending on the action you use, this is no small task. You might as well just switch to something else altogether.
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…
How does this lock down transitive dependencies? Is it effective if the action you rely on doesn't pin its dependencies?
I believe this problem is probably overstated. Can you point us to such an action you are concerned with that has either transitive actions dependency or unlocked npm dependencies where maintainers aren't responsive to addressing PRs to illustrate?
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?
Arguably, that's exactly the one action that will need to be hash-pinned, since all the consecutive actions will at least be verified against the lockfile.
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.