The Rust crate is published to crates.io, and nothing in this repository publishes it.
$ cargo search armonik
armonik = "3.29.1-beta-0" # Rust bindings for the ArmoniK API
$ grep -rn "cargo publish\|CARGO_REGISTRY_TOKEN" .github/ scripts/
(nothing)
So it is released by hand, and it is currently one version behind the repository, which is at
3.29.2-beta-0.
Why that is a problem beyond the missing automation
CONTRIBUTING.md's release process ends with:
And voilà! The new version is released and a CI workflow will publish packages to registries.
That is true for C#, Python, Angular, Web and Java, all of which release.yml handles. It is not true for
Rust, and nothing says so. Whoever follows those nine steps has no way to know that a tenth is needed, or
what it is.
scripts/update-versions.ts does bump the Rust version along with the others, so the repository is
consistent — it is only the publication that is missing. The result is a crate whose version keeps moving in
the repository and only occasionally reaches the registry, with nothing to reconcile the two.
What to decide
- Automate it, in
release.yml alongside the other languages, with a CARGO_REGISTRY_TOKEN secret.
- Document it as a manual step in
CONTRIBUTING.md, and correct the sentence promising CI does it.
- Decide it is not published, and stop bumping its version — in which case the crate on crates.io
should probably be yanked or marked as unmaintained, since it is currently a stale copy under an official
name.
Whichever it is, the release process should say so.
One constraint to know about, if this gets automated
armonik will shortly depend on a second crate in the same workspace, armonik-transport. A path
dependency cannot be published: cargo publish rewrites it into the version requirement recorded next to
it, which must already exist in the registry. So the order is fixed —
cargo publish -p armonik-transport # first, and wait for the index to pick it up
cargo publish -p armonik
— and an automated job has to wait between the two rather than run them in parallel, because the index
takes a moment to become visible. The constraint is documented in the new crate's README, but documentation
is not what would enforce it in a workflow.
The Rust crate is published to crates.io, and nothing in this repository publishes it.
So it is released by hand, and it is currently one version behind the repository, which is at
3.29.2-beta-0.Why that is a problem beyond the missing automation
CONTRIBUTING.md's release process ends with:That is true for C#, Python, Angular, Web and Java, all of which
release.ymlhandles. It is not true forRust, and nothing says so. Whoever follows those nine steps has no way to know that a tenth is needed, or
what it is.
scripts/update-versions.tsdoes bump the Rust version along with the others, so the repository isconsistent — it is only the publication that is missing. The result is a crate whose version keeps moving in
the repository and only occasionally reaches the registry, with nothing to reconcile the two.
What to decide
release.ymlalongside the other languages, with aCARGO_REGISTRY_TOKENsecret.CONTRIBUTING.md, and correct the sentence promising CI does it.should probably be yanked or marked as unmaintained, since it is currently a stale copy under an official
name.
Whichever it is, the release process should say so.
One constraint to know about, if this gets automated
armonikwill shortly depend on a second crate in the same workspace,armonik-transport. Apathdependency cannot be published:
cargo publishrewrites it into the version requirement recorded next toit, which must already exist in the registry. So the order is fixed —
cargo publish -p armonik-transport # first, and wait for the index to pick it up cargo publish -p armonik— and an automated job has to wait between the two rather than run them in parallel, because the index
takes a moment to become visible. The constraint is documented in the new crate's README, but documentation
is not what would enforce it in a workflow.