v5 release broke the tag for v4

[apex-anthonybob]

Describe the bug

As soon as the new v5 version was released, it broke all our usages of v4.

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

v4 should still be a valid version.

Current Behavior

Error: Unable to resolve action aws-actions/configure-aws-credentials@v4, unable to find version v4

Reproduction Steps

any workflow referencing v4 will break.

Possible Solution

No response

Additional Information/Context

No response

[ddk-dbt]

This seems fixed by https://github.com/aws-actions/configure-aws-credentials/releases/tag/v4

[apex-anthonybob]

Yep, it appears so. Thanks for confirming.

[github-actions]

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.

[runspired]

While I can confirm this is working again - it's weird that this even broke folks who use pinned shas for action. This suggests the publishing of v5 unpublished prior commits, not just the tag/branch.

Are there steps that can be taken to ensure this can't occur?

[pauldraper]

it's weird that this even broke folks who use pinned shas for action

Is that true?

Are there steps that can be taken to ensure this can't occur?

Fork or vendor.

This repo could be deleted, compromised (though commits SHAs address that one).

[runspired]

Is that true?

Yes, our workflows use this action like so:

Important

We found we had a shared composite action from another of our repos that had not pinned that may have been why we were susceptible here. Typically renovate automatically updates actions to shas, we are not sure why it had not done so in that repo.

uses: aws-actions/configure-aws-credentials@ececac1a45f3b08a01d2dd070d28d111c5fe6722 # v4.1.0

And the unpublish here broke us until v4 was republished.

Fork or vendor.

I agree that we should consider doing this on our end. That said, I'd expect a repo such as this to be taking precautions around protecting key branches and tags.

[lehmanmj]

Hi there, this was a temporary issue and should be fixed for you now (see https://github.com/aws-actions/configure-aws-credentials/releases/tag/v4).

Recently we made a change so that we are pushing floating version tags pointing to the latest release for that version. A floating version tag involves force pushing the tag, which is an operator-initiated process and is prone to error. During today's release for the latest v5, we mistakenly overwrote the v4 tag as well. Although we corrected this quickly, it looks like your job run occurred right as we were fixing the error. We've also added an extra step in our release procedure to prevent this from happening again. Please let us know if you're still having an issue.

[kellertk]

This repo could be deleted, compromised (though commits SHAs address that one).

We also have immutable releases turned on from 5.0 onward. So a release will be immutable - v5.1.0 will always point to 0094301 - but a tag like v5 will move as we create new releases. That way you can choose whichever works best for you or your automation. (You can tell that a release is immutable because GitHub indicates that on the releases page, and it will have a release attestation attached)