cargo-public-api icon indicating copy to clipboard operation
cargo-public-api copied to clipboard

Add binaries to the releases to support taiki-e/install-action

Open notgull opened this issue 1 year ago • 5 comments

This would allow it to be used in install-action

notgull avatar Feb 08 '24 02:02 notgull

Thank you for the feature request.

Could you elaborate a bit on the use case for install-action please? How come you can't/don't want to use the library + cargo test approach exemplified here?

Enselic avatar Feb 08 '24 05:02 Enselic

It's good form to release a binary when releasing a cargo tool. In addition the added dev dependencies would slow down the build for test runs. I'd rather "quarantine" this tool's build in another test runner.

notgull avatar Feb 08 '24 16:02 notgull

Thank you for elaborating. I think that's justification enough.

Long-term maintainability of this project is high prio, so an implementation of this would need to ensure that this feature works via the CI workflow. I don't think we can do that by actually creating a release, but maybe it is possible to dry-creating release each CI workflow run.

Enselic avatar Feb 08 '24 18:02 Enselic

I've heard good things about https://github.com/axodotdev/cargo-dist, https://github.com/taiki-e/upload-rust-binary-action is also good

It's also not to hard to do this without any external tools except what is already available in CI

As for dry run, a good way to do it imo is to always publish a "Unreleased" tag release which represents the current state.

Emilgardis avatar Feb 08 '24 20:02 Emilgardis

Just happened to come across this issue, so I wanted to share what has been working quite well for cargo-semver-checks: https://github.com/obi1kenobi/cargo-semver-checks/blob/ac0bf46c4ce1ab28532c2839d101df9a083b0e4b/.github/workflows/release.yml#L80-L91

TL;DR: We publish from GitHub, create the release via an action, and use a pretty vanilla setup of taiki-e/upload-rust-binary-action to upload the binaries. We then edit the release notes by hand after-the-fact.

It could certainly be more streamlined as a process (primarily around the release notes), but the "make the GitHub release and add binaries" part is very smooth and we've had zero reason to change it since we set it up.

cargo-dist is also very good, but for the cargo-semver-checks use case it was overkill. I'm happily using it elsewhere though — it really shines when the installer needs to do more than what cargo install would have done on its own.

Hope this is helpful! Happy to answer questions if any come up!

obi1kenobi avatar Apr 16 '24 21:04 obi1kenobi