--tag-only CLI option (without posargs)

[pawamoy]

I'm not sure it's best practice but I currently prefer using tag names rather than commit hashes, and would like to do that for every action appearing in my workflow files, not just specific ones. Therefore I would greatly enjoy a --tag-only CLI option that doesn't require additional positional args (action names) 😄 Nice project!

[davidism]

In general, commit hashes should always be used as they are immutable compared to tags, and so the pins represent a stronger guarantee against unexpected change. The tag is still added as a comment for easy reference.

There is a tag-only option in https://gha-update.readthedocs.io/en/latest/#configuration, to list any actions that should use the tag name instead of the commit hash. This is because the slsa-framework/slsa-github-generator action we use only works if it's pinned by tag name for technical reasons. I considered adding wildcard matches, but I decided that I want users to be very deliberate about this.

[pawamoy]

In general, commit hashes should always be used as they are immutable compared to tags, and so the pins represent a stronger guarantee against unexpected change.

I'm in the "let things break in CI" team. More seriously, I prefer using tags because some actions update their major tags to point to latest ones (v1.2.3 released -> v1 updated to point to v1.2.3). That means less maintenance for me, as I don't have to think about updating these tags often. I don't really need immutability / reproducibility. Same for Python dependencies, I don't track or even generate lock files, I just resolve and install everything in one-go.

There is a tag-only option in https://gha-update.readthedocs.io/en/latest/#configuration, to list any actions that should use the tag name instead of the commit hash. [...] I considered adding wildcard matches, but I decided that I want users to be very deliberate about this.

I'm aware of this option, but it's a bit cumbersome to have to modify my pyproject.toml temporarily to run gha-update. I understand the point about being deliberate, so I'd be fine with a CLI option that asks which action should be updated with tags only. Happy to try and send a PR 🙂

[pawamoy]

I'll still add the usual "we're responsible adults" in favor of some wildcard functionality 😄

[henryiii]

GitHub Actions is not a static platform. The base images updates regularly, and those updates are often why patch releases of actions are made, especially official actions. For example, they updated the version of Powershell on all the images, which broke cibuildwheel's action. We released (IIRC) v2.16.5 to fix it, but anyone pinned to any patch version now has a broken workflow. But if you pinned to v2.16, then your workflow didn't break (except for the 24 hours or so it took us to fix and release). (We don't allow pinning to v2, by the way, since we only guarantee stability for patch releases, minor releases can drop or add wheels and modernize defaults).

The official actions (actions/*) often talk to something that changes. setup-python interacts with the python-versions database. Download/upload artifact talk to GitHub APIs. And they are very stable - I'd say the chance of a patch breaking things is a lot lower than a patch fixing things due to the dynamic nature of the runners and actions framework. and adding pins adds a lot of constant churn as well, and means branches more quickly get out of date, etc. You also would avoid remaining vulnerable to CVE's like CVE-2024-42471 if you use moving tags. From the advisory:

Upgrade to version 4.1.7 or higher. Alternatively use 'v4' tag which points to the latest and secure version.

I generally only use the hashed style for parts were security is important, like the artifact action, and for actions I'm not as sure will be stable as official or very well developed actions, and use the moving tag for actions that recommend it.

What I'd really like is for gha-update to not change the style that it finds unless a command line argument is passed, like --hash. Tags would be updated to the newest tag with the same number of dots as the current tag (v1 -> v2 but not -> v2.0.0, just like GHA's updater). Hashes get updated to the new hash - the style is simply preserved. After the initial run, you don't ever need to update the style again anyway, so preserving style seems like a better default. I'd expect a tool called "update" to just update actions, and not also force some style on me that I'm not using (without me asking, that is). Dependabot does exactly this.

I'd actually really like to have the option to move to --hash style like the current default, I'd use that to move some actions over; some actions I probably should be hashing, like setup-uv, but am not because it's trouble to look up the hash to set it up.

I'd also be (slightly less) happy with a way to opt out of this change instead of a way to opt-in. I'd not call it "tag-only" though, as I'd expect to to preserve the styles per usage.

[davidism]

Download/upload artifact talk to GitHub APIs. And they are very stable - I'd say the chance of a patch breaking things is a lot lower than a patch fixing things

Download/upload just broke compatibility in a patch by changing how . prefixed files are handled. There's plenty of discussion already about how the only thing you can actually rely on about version numbers is that they increase over time to indicate change, nothing else. The point of pinning is to avoid any unexpected changes.

The OSSF Scorecard requires pinning Actions by hash https://github.com/ossf/scorecard/blob/main/docs/checks.md#pinned-dependencies. While the scorecard has its problems, I don't think this is one of them.

You pin your dependencies for stability. You update at a frequency that is appropriate for your project. How you pin shouldn't affect how often you check for updates.

[henryiii]

Yes, but my point is that you can't pin the runners or the APIs the actions talk to (like setup-python talking to python-versions), and they can and do break pinned actions. A minor or patch release can break unpinned actions, but a runner update can break pinned actions. I'd just like "gha-update" to work with both styles, rather than forcibly changing everything to one without asking it to. I'd settle for a way to opt-out of the change, though keeping the status-quo if not asked seems nicer.

[webknjaz]

It would be nice to have support for keeping the branch-based version streams too. My actions have rolling pointers like release/v2 which are branches because I'm pretty much against the idea of mutable tags. I have tags too for the specific versions but the rolling ones are implemented through branches. Examples: https://github.com/marketplace/actions/checkout-python-sdist / https://github.com/marketplace/actions/pypi-publish.

[davidism]

I've thought about this a lot, and am deciding I don't want to support wildcards. As I said in my first comment:

I considered adding wildcard matches, but I decided that I want users to be very deliberate about this.

I don't feel the possibility that the underlying runner could change behavior to be convincing enough. I don't have any control over how the runner works, but that doesn't mean I should compromise on what I do control. It feels like the same could be argued about pinning test dependencies, if there's a bug you don't get the fix for it until you update, and that feels like a common accepted position. I have never observed a runner breaking an action, but iff it did, fixing that is a call to gha-update away, assuming the action has fixed its compatibility. That's sort of the whole point, you control when you update (regardless of reason), rather than getting updates on floating tags or branches.