`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.