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.

▲

baobun 2 days ago | parent | next [-]

This is the way to do it.

Pin by hash.

Verify that the actions themselves aren't pulling in unpinned dependencies from Actions, NPM, or elsewhere.

Have a CI job or bot create PRs for new versions. Verify those PRs before merging.

If any particular action becomes a recurring chore or risk, consider if you should keep depending on it.

If you do these things, the "we need a package manager" is moot and most if not all of the concerns in that blog post don't affect you.

	▲	larusso 2 days ago \| parent [-]
		I don’t want to throw process at the problem. I think GH should provide a better system not the developers locking down dependencies and adding extra processes and steps to update the CI via a PR workflow. Not like PRs became the development bottleneck anyways for a lot of development teams these days. I wonder how we functioned 15 years ago with trunk based YOLO development. I also think that it wasn’t the best idea to base versioning on mutable branches and not introduce a registry in the middle. Think about it. The whole system is build on node anyways. But we pull “dependencies” via a weak git clone system.

▲

g947o 2 days ago | parent | prev [-]

How does this lock down transitive dependencies? Is it effective if the action you rely on doesn't pin its dependencies?

	▲	baobun 2 days ago \| parent [-]
		You don't use actions pulling in unpinned dependencies outside of trusted distro package manager at runtime. 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?