Closed mathew-fleisch closed 2 years ago
Ugh, Cargo and its insistence on version numbers in files. So over it.
I think I'll just workaround that by setting a static, obviously-not-released version number in Cargo.toml
and then replace it with the real version number (taken from the tag, as $DEITY intended) in the release workflow.
As for asdf
not picking up the correct latest
version, which I feel like is the real problem you're interested in, I've figured that out and pushed a fix that seems to do the trick. Feel free to reopen if I've only treated part of the symptom.
Cool. Thanks. works for me now
$ asdf install action-validator latest
Downloading [action-validator] from https://github.com/mpalmer/action-validator/releases/download/v0.1.2/action-validator_linux_amd64 to /tmp/asdf_b8DoXlrT/action-validator_0.1.2
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 636 100 636 0 0 2373 0 --:--:-- --:--:-- --:--:-- 2364
100 7758k 100 7758k 0 0 5256k 0 0:00:01 0:00:01 --:--:-- 12.2M
Creating bin directory
Cleaning previous binaries
Copying binary
$ asdf global action-validator latest
$ action-validator --version
action-validator 0.1.2
There seems to be a problem with the versions now that you've released v0.1.1.
First, the asdf plugin is not selecting the newest version as the latest version
Second, there seems to be a version mismatch with the cargo configuration vs git tag / git release. https://github.com/mpalmer/action-validator/blob/main/Cargo.toml#L3
Perhaps you can automatically set the version (commit the version change via github-action): https://github.com/mpalmer/action-validator/blob/main/.github/workflows/release.yml
I've done this sort of thing here: https://github.com/mathew-fleisch/bashbot/blob/main/.github/workflows/update-asdf-versions.yaml
The flow I follow in this automation is a cron will check for new asdf plugin versions, and update the .tool-versions if any new versions are found. The automation will then automatically bump a semver patch
git tag v#.#.#
committing that back to the repo with an automation token; that will then trigger a git release, build go-binaries (saving to release), build docker containers. You could potentially use a similar set of automation that could set that cargo version number when agit tag
is issued. Just an idea 🤷