Tag all releases

[robo9k]

The README.md suggests:

- uses: rui314/setup-mold@v1

However the latest and only "v1" tag has not been updated for the recent commits, e.g. https://github.com/rui314/setup-mold/compare/v1..main

It would be best if each "release" gets its own tag. e.g. "v1.0.2" and a major version tag such as "v1" gets updated continously, see https://docs.github.com/en/actions/creating-actions/about-custom-actions#using-release-management-for-actions
This would also help for pinning full-length sha with a version comment for https://docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot

If you'd rather not do tags, I suggest you update your doc to:

- uses: rui314/setup-mold@main

See https://docs.github.com/en/actions/creating-actions/about-custom-actions#using-branches-for-release-management
This way users of the action constantly get (possibly breaking) updates.

[rui314]

Thank you for the suggestion, but I'm not sure if we want to tag a specific version of this repository itself; it is after all just a tiny action.yaml file. What user would want to do is to choose the version of the mold linker itself, and that can be done with mold-version YAML option. So just v1 would serve the purpose, no?

[robo9k]

If you don't intend to change anything in the action other than the default mold version https://github.com/rui314/setup-mold/blob/354d1662b2a6f02e5eccc9712f22657621bf645b/action.yml#L6C5-L6C21, then yes - users could just use v1 of the action and explicitly set the mold version instead.

But in that case, why do you even create commits such as "Bump mold version to x.y.z"? The users won't use that new default if they still use the old "v1" tag as your readme suggests them to do.
Furthermore "By default, the most recent version will be installed." is wrong since "v1" of the action will only ever install 2.0.0 currently, while at the time of writing 2.2.0 is the latest mold version.

[rui314]

I usually don't increment the default v1 version immediately after I make a new release. Instead, I advance only the staging tag to refer to the latest version and see if everything is okay. The thing that v1 pointed to 2.0.0 was just my mistake -- it now refers to version 2.2.0.