CI: Add a release preparation and release workflow

[photovoltex]

I think this is in a reviewable state now, where we can discuss over the details.

The idea behind the release flow is described in PUBLISHING.md. But broken down, there is a manual workflow that takes care of the manual preparation steps and a automatic workflow that is triggered when a github release is created (only created because we want to create a draft and only publish when the workflow is done).

Maybe we could also use this already for 0.7.1, then we would see how only some crates are updated as only playback, connect and core changed so far.

Disclaimer:

• what is missing for this to work:
  • we need to at a secret to the repository for crates.io access
• what I couldn't test so far:
  • commit and pushing in the preparation workflow
  • the publish itself in the release workflow, but as dry-run it seems to work well

[roderickvd]

Ooohh, from Rust 1.90.0 release:

Cargo adds native support for workspace publishing

cargo publish --workspace is now supported, automatically publishing all of the crates in a workspace in the right order (following any dependencies between them).

This has long been possible with external tooling or manual ordering of individual publishes, but this brings the functionality into Cargo itself.

Native integration allows Cargo's publish verification to run a build across the full set of to-be-published crates as if they were published, including during dry-runs. Note that publishes are still not atomic -- network errors or server-side failures can still lead to a partially published workspace.

[photovoltex]

I'm currently adjusting the release workflow to use that new info. How does that interact with crates that generate code and need --no-verify as flag, like protocol? Does that mean you have to use --no-verify for the entire workspace then?

[photovoltex]

I tested the workspace publishing with a dry-run for a patch version and that seemed to work quite well. So I adjusted the release workflow to use that, as it reduces a lot of unnecessary complexity

[roderickvd]

What's the current state? You think we could try next release with it? 🤞 (not now but when we're ready for a new release)

Edit: asking because I saw more than a few review comments as not resolved yet.

[photovoltex]

I think I did go over every comment of yours and changed/adjusted the code or added a comment to it explaining why I would like it to be as is.

[kingosticks]

I can look over this tomorrow eve, if that's helpful.

[photovoltex]

@roderickvd @kingosticks Anything that requires doing on this PR? Otherwise we could use this for the next minor version release then?

[roderickvd]

Would be great to give it the shot! Next release should be v0.8.0 no? Because of the various breaking changes to the API.

[photovoltex]

Yeah, 0.8 would be the next version. I just now resolved all open discussion. The next version will be interesting as the protocol will be updated too and we don't provide the no-verify flag (see the quote comment from the old script). So this flow might still be faulty, but I didn't wanted to invoke the entire publish with the no-verify flag.

Protocol crate needs --no-verify option due to build.rs modification.

[photovoltex]

To use the workflow we still need to add a secret to the repository named CARGO_REGISTRY_TOKEN with a token from crates.io, so that it can publish automated. @roderickvd I think you are the only one who has access to the account currently, could you take care of that?

When that is done, I would merge this PR and see how good it works for 0.8 if no one has a problem with that?

[roderickvd]

OK, I've added an CARGO_REGISTRY_TOKEN repository secret with publish-update and yank authorization on the librespot crate. By all means give it a try and release v0.8.0!

[photovoltex]

So first issue encountered. The action can't automatically commit on dev and it states a PR is required. Will see what the best solution is. ctx: https://github.com/librespot-org/librespot/actions/runs/19214559117/job/54921880838

[photovoltex]

I added the maintain role to the ruleset, which can now bypass the restriction on all branches. That should probably be fine?

[photovoltex]

Hmm, those ruleset settings are quite annoying. Even tho I added myself via a group to a bypass list, it doesn't bypass the ruleset... And I don't want to disable the PR required rule as it seems quite important to have.