cargo-smart-release feature request: some way to make it easier to make linux distro packages

[dyc3]

steamguard-cli is a binary crate. During my release process, I package up the artifacts in a .deb for ubuntu/debian, and update PKGBUILD for releasing on the AUR.

I've attempted to automate most of it, with mild success: https://github.com/dyc3/steamguard-cli/blob/master/scripts/full-release.sh

Obviously, its preferable to have the whole process automated. The problem with my current approach is that it relies on grabbing the version from the output of the built binary, which is pretty brittle, and desynchronizes easily with smart-release when doing a dry-run. This could be remedied if smart-release could output the version number somewhere, but I think it would be pretty great to integrate packaging into smart-release. If not, maybe release lifecycle hooks?

Potential solutions:

1. Output the version that smart-release would prepare at the very end of all output on stdout. This would make it at least possible to script, although this feels pretty brittle.
2. Add packaging smart-release. This could be a lot of work, or it could be not possible within reason, because different distro's tooling might not work on other distros.
3. Release lifecycle hooks that work similarly to how git hooks work. This would allow smart-release to provide whatever info could be necessary to set package metadata.

[Byron]

Thanks for the suggestion, here is my thoughts.

2. Add packaging smart-release. This could be a lot of work, or it could be not possible within reason, because different distro's tooling might not work on other distros.

This is seems like it's absolutely out of scope for a tool that helps with publishing Rust crates. However, providing more support seems viable, as is also suggested.

1. Output the version that smart-release would prepare at the very end of all output on stdout. This would make it at least possible to script, although this feels pretty brittle.

It seems easy to implement collecting some data about the would-be or actually-performed operations and output them as JSON for scripts to pick up. Maybe this is just a less desirable version of 3) depending on the use-case.

3. Release lifecycle hooks that work similarly to how git hooks work. This would allow smart-release to provide whatever info could be necessary to set package metadata.

Even though it would be possible to have shell scripts hook into the release process quite trivially, additional discussion would be needed to learn how these would want to interact and possibly affect the ongoing smart-release process.

We could discuss this more to see what minimally intrusive options there would be to get you what you need, so a PR would be viable. As cargo smart-release is really a tool to help with the needs of releasing this project, it's unlikely I will be implementing any of it though.

[dyc3]

I'm leaning towards lifecycle hooks being the best option, because I think it would allow for the most amount of flexibility on both the smart-release side and the user side, while still being fairly self contained as a feature.

I'm thinking:

• hook scripts stored in <root>/.smart-release/hooks/
• if a hook script fails, the release process aborts
• parameters are passed to hook scripts by environment variables

There's also the slight problem of cross platform compatibility (with windows specifically).

I'd like to take a stab at implementing this, but I won't be able to start it for a little while.

[Byron]

I'm leaning towards lifecycle hooks being the best option, because I think it would allow for the most amount of flexibility on both the smart-release side and the user side, while still being fairly self contained as a feature.

Great, I liked that one too.

hook scripts stored in /.smart-release/hooks/

Here I would love if hooks would be enabled by specifying a --hooks <directory>. If non-existent or empty, it will be created with all supported hooks provided as no-op sample shell-scripts, possibly printing their arguments or input environment variables. The latter I'd probably use for general context while the passed arguments are more about what's currently to be done.

There's also the slight problem of cross platform compatibility (with windows specifically).

Yes, even though I think it should only be a problem for shell scripts. Maybe it's OK to assume these are executables and all we do here is to append .exe to them as best-effort implementation. From there it can improve if there's demand.

I'd like to take a stab at implementing this, but I won't be able to start it for a little while.

Lovely, take your time.

[dyc3]

Ok, so it's been a couple months years (whoops), and I don't think I'm going to get around to working on this (sorry). After doing a bunch of releases recently, I've learned that what I really want is to make sure that my artifact builds succeed before git pushing tags and cargo publishing versions, which I'm pretty sure I can do with the existing cli args.

It could be made simpler if it was split up into a 2 phase process: a "prepare" phase and a "release" phase.

• "prepare" would make changes locally but not push them to anywhere else
• "release" would actually push the changes and do the crate publishes

IDK how difficult that would be to implement though.

[Byron]

Indeed, this is already implemented and "prepare" can be achieved by adding the various --no-* flags, like --no-publish and --no-push, maybe more.

Then one can repeat the release without the --no-* flags to see it through, probably after making modifications.

[dyc3]

Ok, I just tried doing a release like that and I got

[WARN ] Using 'steamguard-cli' as crate name as no one was provided. Specify one if this isn't correct
[WARN ] Refused to publish 'steamguard-cli' as as it didn't change.
Error: No provided crate is actually eligible for publishing. Use --verbose to see the release plan nonetheless.

More specifically,

1. cargo smart-release --no-push --no-publish
2. build, create packages, etc.
3. cargo smart-release

Is there a way to get it to push the tags and do the publishes or do I have to do those myself?

[Byron]

Oh, I see. I think the first line should also be --no-tag - that way it should still detect changes in the final smart-release call which then should do the actual work. You can also try to delete the tags it created previously to get to the same state.

For a general understanding, it uses git tags to know what changed since the last release of a package.