Summary
gh aw upgrade bumps action versions in actions-lock.json but does not update the uses: reference in workflow or shared-component .md source files. This leaves a dangling lockfile entry that nothing resolves — compiled .lock.yml files continue using the old version until the developer manually edits the source.
This happens regardless of whether the action reference is in a shared component or directly in a workflow .md file.
Steps to Reproduce
- Have a workflow or shared component that pins an action version:
steps:
- name: Set up Ruby
uses: ruby/setup-ruby@v1.309.0
- Run
gh aw upgrade
- Observe output:
ℹ Updating GitHub Actions versions...
✓ Updated ruby/setup-ruby from v1.309.0 to v1.310.0
✓ Updated 1 action(s):
• ruby/setup-ruby
ℹ Updated actions-lock.json file
Actual Result
actions-lock.json now has both v1.309.0 and v1.310.0 entries
- The source
.md file still says ruby/setup-ruby@v1.309.0
- All
.lock.yml files still compile against the old SHA
- The v1.310.0 lockfile entry is unused/dangling
- Same behavior whether the
uses: is in a shared component or a main workflow .md
Expected Result
Either:
gh aw upgrade updates the uses: version in the source .md file(s) and adds the lockfile entry (fully automated upgrade), or
gh aw upgrade only reports the available update without modifying actions-lock.json, deferring the lockfile entry to gh aw compile after the developer bumps the source
The current behavior is an incomplete middle ground — it claims the update succeeded but nothing actually consumes the new version.
Environment
- gh-aw v0.74.8
- Action affected:
ruby/setup-ruby (v1.309.0 → v1.310.0)
Summary
gh aw upgradebumps action versions inactions-lock.jsonbut does not update theuses:reference in workflow or shared-component.mdsource files. This leaves a dangling lockfile entry that nothing resolves — compiled.lock.ymlfiles continue using the old version until the developer manually edits the source.This happens regardless of whether the action reference is in a shared component or directly in a workflow
.mdfile.Steps to Reproduce
gh aw upgradeActual Result
actions-lock.jsonnow has both v1.309.0 and v1.310.0 entries.mdfile still saysruby/setup-ruby@v1.309.0.lock.ymlfiles still compile against the old SHAuses:is in a shared component or a main workflow.mdExpected Result
Either:
gh aw upgradeupdates theuses:version in the source.mdfile(s) and adds the lockfile entry (fully automated upgrade), orgh aw upgradeonly reports the available update without modifyingactions-lock.json, deferring the lockfile entry togh aw compileafter the developer bumps the sourceThe current behavior is an incomplete middle ground — it claims the update succeeded but nothing actually consumes the new version.
Environment
ruby/setup-ruby(v1.309.0 → v1.310.0)