Allow specifying the version of `cargo semver-checks`

[thomaseizinger]

Hi!

I'd like to move our custom action over to this but I am concerned with the automatic download of the latest release.

I'd like to pin the version of cargo semver-checks to make sure CI checks are reproducible and deterministic. Passing semver check is a merge requirement in our CI and updates to our tooling (Rust toolchain, clippy, etc) must go through a PR like any other change.

We are also pinning the versions of actions to a commit hash[^1][^2]. My suggestion would be to hardcode the release to download with the action version. This way, users who just depend on this action with @v2 will always use the latest version and people who pin action version will have deterministic builds without needing to configure anything.

The only downside is that a new release of cargo semver-checks requires a new release of the action but IMO that is a small price to pay for the advantages we get from it.

[^1]: This is recommended by GitHub: https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions [^2]: Dependabot will send PRs for new releases of these actions.

[obi1kenobi]

I'm open to the idea in general.

I'm hesitant to add more operational steps to making a cargo-semver-checks release, since free open-source projects live and die based on their maintenance load. I understand it's recommended practice by GitHub, but in practice very few people seem to follow it (e.g. nobody else has brought it up thus far) and the extra burden for that practice falls solely on me.

Is there a way to get the same effect without the ongoing operational burden?

[thomaseizinger]

We can add another configuration option to the action that allows you to specify the version to use (and default it to latest).

Personally, I find less configuration options better but I also fully understand that you want to minimize the amount of work that comes with a release.

I am happy to help with some release automation for the action in case that would make a difference to you!

[obi1kenobi]

Thanks, I appreciate the offer! Let's do a config option that defaults to latest for now. Would you be able to open a PR for that?

Release automation is nice but it's still one more thing I need to monitor, so I think I prefer this approach for now.

[thomaseizinger]

Thanks, I appreciate the offer! Let's do a config option that defaults to latest for now. Would you be able to open a PR for that?

Yes, likely in the upcoming days.

[thomaseizinger]

I've done some more work on https://github.com/obi1kenobi/cargo-semver-checks-action/pull/48 and I am not sure I am entirely happy with it. Specifying the version at runtime leads to more error cases and more code to maintain.

For example, I tried testing this in https://github.com/libp2p/rust-libp2p/pull/3923 and I am not sure why my invalid version is not being picked up.

If additional work when making a release of cargo semver-checks is what you are worried about, would you be open to adding some automation to this repository instead that deals with this? I think pinning the version of the tool within the action is the much cleaner solution.

[obi1kenobi]

For example, I tried testing this in libp2p/rust-libp2p#3923 and I am not sure why my invalid version is not being picked up.

We need better contributor onboarding, sorry about that.

As far as I know, GitHub Actions can only run Javascript, not Typescript, so actions written in Typescript usually have a src directory with the source, a dist directory with the compiled Javascript (which is what GitHub actually runs), and a CI check or other automation that ensures every change to src is reflected in dist.

Your PR modified the source but didn't rebuild the Javascript that GitHub actually runs, which is why your tests still used the old code paths.

would you be open to adding some automation to this repository instead that deals with this? I think pinning the version of the tool within the action is the much cleaner solution.

Unfortunately, even with automation, it's yet another thing I have to monitor and maintain. As we've already talked about, I must avoid taking on more ongoing maintenance burden while this is just a fun side-project for me and not something that helps me pay my rent with hundreds if not thousands of dollars per month.

[thomaseizinger]

As far as I know, GitHub Actions can only run Javascript, not Typescript, so actions written in Typescript usually have a src directory with the source, a dist directory with the compiled Javascript (which is what GitHub actually runs), and a CI check or other automation that ensures every change to src is reflected in dist.

Your PR modified the source but didn't rebuild the Javascript that GitHub actually runs, which is why your tests still used the old code paths.

Ah silly me, I forgot about that! I'll try with re-compiled sources.

If you want, I can contribute what I did for one of my own TS actions: https://github.com/thomaseizinger/keep-a-changelog-new-release/blob/master/.githooks/pre-commit

It is a pre-commit hook that reminds you to re-compile TypeScript whenever you change the sources.

[thomaseizinger]

would you be open to adding some automation to this repository instead that deals with this? I think pinning the version of the tool within the action is the much cleaner solution.

Unfortunately, even with automation, it's yet another thing I have to monitor and maintain. As we've already talked about, I must avoid taking on more ongoing maintenance burden while this is just a fun side-project for me and not something that helps me pay my rent with hundreds if not thousands of dollars per month.

Makes sense! I'll continue with my PR then :)

[thomaseizinger]

I am closing this in favor of manually install cargo-semver-checks in the PR first. Given that the action checks for the existence of the binary before downloading, this is good enough to support reproducible CI.

[thomaseizinger]

I am closing this in favor of manually install cargo-semver-checks in the PR first. Given that the action checks for the existence of the binary before downloading, this is good enough to support reproducible CI.

See https://github.com/libp2p/rust-libp2p/pull/3923.

[obi1kenobi]

I forgot we did that in the action, what a pleasant surprise 😅 Thanks for looking into this!