fix(presets): fix helpers:pinGitHubActionDigestsToSemver

[amezin]

Changes

Fix helpers:pinGitHubActionDigestsToSemver to really do pinning.

Context

• The preset with regex versioning failed in some cases - for example, with codeql-action: `helpers:pinGitHubActionDigestsToSemver` causes some actions to be skipped with `"skipReason": "invalid-value"` #36322 (because there's no v3.0.0 tag in the repository).

• When it didn't fail, it created "update" pull requests, not "pin" - Update actions/checkout action to v4.2.2 amezin/renovate-pin-actions-digest-semver-codeql#5

• Also, the description was misleading. It didn't convert from digest pinning to version. It just changed the version in the comment.

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[rarkins]

This changes the meaning/behavior of this preset. Originally created in #23663

[amezin]

This changes the meaning/behavior of this preset

Are there any behavior changes that I didn't list under "Context"?

Because I tested the original helpers:pinGitHubActionDigestsToSemver and then my changes, and I haven't noticed any other differences.

#23663 (comment)

If no SHA exists, and pinDigests=false, leave it alone

The original helpers:pinGitHubActionDigestsToSemver preset includes pinDigests: true too (extends: ['helpers:pinGitHubActionDigests'] hasn't changed). Both before and after the change, the preset just always adds both the digest and semver (except when the old version fails because of lack of v*.0.0 tag).

Example of the original preset adding a digest: https://github.com/amezin/renovate-pin-actions-digest-semver-codeql/pull/4/files

If a SHA exists, but no version comment, then add it

Does this both before (unless the original preset fails with "skipReason": "invalid-value") and after the change.

If a SHA exists and version comment, but it's not pinned to semver, then pin it

Does this both before (unless the original preset fails with "skipReason": "invalid-value") and after the change.

Example after: amezin/create-or-update-git-ref-action#17

So what am I missing?

[rarkins]

@travi @TWiStErRob @suzuki-shunsuke @MPV you were all involved in the original #23663. Can you take a look at the proposed changes here?

[travi]

i'll admit that i dont have this all in my head at the moment, but i'm happy to be pulled deeper if specific details need additional consideration. overall, i've been quite happy with how this preset behaves. there certainly may be some cases where it is not behaving as expected, so i'm glad to see some attention given.

• because there's no v3.0.0 tag in the repository

this detail confuses me. i can understand that a missing tag would result in a failure to pin to that version, but i guess it maybe exposes a potential improvement in the pinning behavior. when pinning v3, i wouldnt actually want it to pin v3.0.0 anyway, assuming that other valid versions exist under the v3 major. when a workflow that defines a v3 version runs, it doesnt pull v3.0.0, it pulls the latest in that major (well, assuming the v3 tag is moved accordingly, as is convention). when pinning, i want to pin the current behavior, not downgrade to a previous version.

naively , i would expect the pinning to pin the latest version in that major, but i guess the ideal behavior would be to pin the hash of the commit that that v3 tag points to, regardless of semver association. that pins the existing behavior of how the workflow was already working. by convention, the major tag should also have another tag for the more specific version, so if that exists, the comment for the corresponding semver comment should ideally be pulled from that other tag for the same commit. if that other tag does not exist, i would expect the pinning to still happen and pin to the hash, but not include a semver comment. then, after that is merged, i would expect an update PR to "upgrade" to the latest full semver version. i guess the downside of this approach is that the followup to add the comment could be a downgrade if the tags arent being managed properly, but that is the nature of versioning with tags rather than a proper registry

• When it didn't fail, it created "update" pull requests, not "pin"

this may be why i havent noticed this scenario. i think this is in line with the outcome that i desire, even if the order of operations and the description could be improved. as described above, after pinning the currently used version, my end goal is to get upgraded to the latest and be pinned there, so this step hasnt felt wrong. maybe it just isnt the ideal path to get there?

[travi]

it feels risky to use npm versioning here because there can be variation to how folks define tags for actions that might not align to the npm standards. i imagine this works in many cases, but would this set us up to miss some scenarios?

[amezin]

The thing that's currently in main

       versioning:
          'regex:^v?(?<major>\\d+)(\\.(?<minor>\\d+)\\.(?<patch>\\d+))?$'

rejects all dependencies for which currentValue doesn't match the regex (and yes, it again causes Renovate to completely stop processing these non-matching dependencies, completely silently). versioning: 'npm' is actually less restrictive - it accepts v1.x, for example.

And extractVersion filters out everything that isn't exactly 3 numbers - more restrictive than npm/semver too.

[travi]

i agree that this is a step in the right direction. just calling out that there is nothing about actions versioning that relates it to npm versioning specifically. mainly wondering if it warrants its own "versioning" classification. others are probably more informed than me here, so just trying to call it out

[amezin]

just calling out that there is nothing about actions versioning that relates it to npm versioning specifically

Both are semver "with ranges". For actions it's not enforced, but the recommended versioning matches - https://docs.github.com/en/actions/sharing-automations/creating-actions/releasing-and-maintaining-actions#example-developer-process

Also, the same page has a link directly to https://docs.npmjs.com/about-semantic-versioning

mainly wondering if it warrants its own "versioning" classification

Maybe, but right now it does not exist.