You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature Request: Allow --relock without updating mutable ("floating") tags #238
As found while integrating with the new --relock flag in #134 (as reported as needed in renovatebot/renovate#47292), we found that the --relock (which is needed when i.e. performing a patch bump on a full version-pinned tag) will also bump any mutable ("floating") tags
Having the option of not doing that would be appreciated, so changes can be isolated to only the Action that's actually changing (unless it's changed transitively)
Thanks for raising this, and for the work on the Renovate integration!
You shouldn't need --relock for a version bump. It's meant for refreshing everything, which is why it also moves every floating tag. For a single update, edit the uses: ref in the workflow and then run the normal lock command:
# after rewriting e.g. actions/setup-go@v5.0.0 -> @v5.0.1 in the workflow
gh actions-lock --no-onboard --no-narrow --no-interactive .github/workflows/ci.yml
The default run re-resolves only lock entries whose ref changed. Every other pin stays exactly as locked, including floating tags like @v4 that have moved upstream. So the diff only shows the bumped action and anything new it pulls in transitively.
--no-onboard stops the run from adding workflows that aren't in the lockfile yet.
--no-narrow keeps the ref exactly as Renovate wrote it, so v4 isn't rewritten to v4.x.y.
You can pass the changed workflow paths, or omit them to scan everything.
This is the same thing Dependabot does. Its flags are in cli_engine.rb#L58-L80. It also passes --ignore-local-actions and --json=findings.
In my actions, I also explicitly use branches instead of tags for anything mutable/“floating” (been doing that long before GH introduced the immutable releases feature toggle due to https://julienrenaux.fr/2019/12/20/github-actions-security-risk/ so since around 2018/2019).
I have explicit branches like unstable/v1, release/v1 and release/v1.14 that reflect that — the moving pointers. And the tags like v1.14.3 that never move (and are GPG-signed).
Activity
nodeselector commentedon Oct 23, 2026
Thanks for raising this, and for the work on the Renovate integration!
You shouldn't need
--relockfor a version bump. It's meant for refreshing everything, which is why it also moves every floating tag. For a single update, edit theuses:ref in the workflow and then run the normal lock command:# after rewriting e.g. actions/setup-go@v5.0.0 -> @v5.0.1 in the workflow gh actions-lock --no-onboard --no-narrow --no-interactive .github/workflows/ci.ymlThe default run re-resolves only lock entries whose ref changed. Every other pin stays exactly as locked, including floating tags like
@v4that have moved upstream. So the diff only shows the bumped action and anything new it pulls in transitively.--no-onboardstops the run from adding workflows that aren't in the lockfile yet.--no-narrowkeeps the ref exactly as Renovate wrote it, sov4isn't rewritten tov4.x.y.This is the same thing Dependabot does. Its flags are in cli_engine.rb#L58-L80. It also passes
--ignore-local-actionsand--json=findings.webknjaz commentedon Oct 25, 2026
In my actions, I also explicitly use branches instead of tags for anything mutable/“floating” (been doing that long before GH introduced the immutable releases feature toggle due to https://julienrenaux.fr/2019/12/20/github-actions-security-risk/ so since around 2018/2019).
I have explicit branches like
unstable/v1,release/v1andrelease/v1.14that reflect that — the moving pointers. And the tags likev1.14.3that never move (and are GPG-signed).Would it be possible to add some config toggle to treat certain user-defined patterns similar to that
v4? This would cover actions like https://github.com/marketplace/actions/pypi-publish.