build: strip release binaries and gate publishing on CI

Two gaps left over from the v6.0.0 release.

The v6.0.0 archives shipped unstripped: 3.63 MB vs 4.53 MB locally, 168
symbols instead of 9483. Setting it on the profile rather than in the
workflow covers every target at once and `cargo install` along with them.

Nothing gated the crates.io publish. A published version can be yanked but
never withdrawn, so the release job now waits for the CI run on the same
commit and refuses to publish unless it is green. release-pr deliberately
does not wait; opening the release PR is harmless.

This is not hypothetical: CI failed on eef7bf7, the v6.0.0 release commit.
It was a flaky e2e timeout rather than a regression - the very next commit
touched no code and passed - but the gate would have stopped that release,
which is the point. The gate reads the newest CI run for the commit, so
re-running a flaky job and then re-running Release clears it.
This commit is contained in:
Michel de Graaf
2026-07-24 13:27:09 +02:00
parent 237068cc2c
commit 298ec5aad5
3 changed files with 60 additions and 1 deletions
+7
View File
@@ -9,6 +9,13 @@ edition = "2024"
license = "MIT"
repository = "https://github.com/michel/soulseek-rs"
# The v6.0.0 release binaries shipped unstripped: the Linux archives were
# roughly twice the size of the macOS ones purely because of debug symbols.
# Doing it here rather than in the workflow covers every target at once,
# including `cargo install`.
[profile.release]
strip = true
[workspace.lints.rust]
unused_lifetimes = "warn"
unsafe_op_in_unsafe_fn = "warn"