Running this as part of the release workflow would be the real value here, so I think it would make sense to invest more time into seeing if we can extract the part of the publish action that does this check.

Actually, the release workflow is already too late -- this needs to be a regular workflow that is run on the "bump" commit (or any commit that updates the language crate).

See also katyo/publish-crates#663

Actually, the release workflow is already too late -- this needs to be a regular workflow that is run on the "bump" commit (or any commit that updates the language crate).

Couldn't we run it as part of the release workflow before the steps creating the releases (e.g. alongside the tests)? I'm not sure how we'd set up triggers for the workflow to only run on "bump" commits, and if we run it on every PR then it may get ignored.

If it's part of the release workflow, it runs after we bumped and tagged -- so if we do need to bump the language crate, we can only do it after the bump, so we'd have to fix, bump, and tag again, same as now.

As to how: we can gate this either behind the commit message (regex) or a label we apply to release commits.

Running this as part of the release workflow would be the real value here, so I think it would make sense to invest more time into seeing if we can extract the part of the publish action that does this check.

After spending a few too many hours on the xtask implementation, I think I agree with this approach. We may even be able to run the workflow with dry-run=true and not have to extract anything (needs to be tested).

Solely so I can document this somewhere the xtask approach consisted mainly of the following:

• Grab crate versions from the local checkout
• See if those versions exist on crates.io
• If they do, get their sha256 checksum
• Create package of corresponding crate locally
• Compare checksums (a small amount of shenanigans are required to get the repo's current commit sha out of .cargo_vcs_info.json)

The issue is that the cargo package command has a bug in its tar dependency, which seems to sometimes append 4 \0 bytes to the end of the .crate file, sometimes not. This changes the checksum, and everything kind of falls apart. I also tried another approach where we pulled down the published .crate file, extracted it, and then manually hashed that against a locally created .crate file, but the same tar issue shows up and needs workarounds, and there's still the issue with .cargo_vcs_info.json. Too much complexity and way too many places where this could break.

I've added a new workflow, which is just the normal rust publishing job katyo/publish-crates@v2 with dry-run set to true. (TBD if we need to supply our token to use github's API to check for changes to crates). This should be tested on this PR, on its own backport PR (once this is merged), and again on a separate backport PR to the release branch (#5295 should be backported, but I'm waiting to so we can test both cases). I also need to add the option to trigger this workflow manually, but that is going to be a tomorrow problem.

I pushed a commit with a proposed release workflow listing individual steps. (It's a bit of a pity that we don't have any changelog or similar that could be edited for the minor release PR; we might want to put a nonce somewhere, e.g. in the README, for that purpose.)

Going to merge this now as-is. This is an opt-in change and the docs are also a nice win to get in. If there's any followup issues we run into, further testing can be done on my fork before fixing in one PR.

Backport failed for release-0.26, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin release-0.26
git worktree add -d .worktree/backport-5292-to-release-0.26 origin/release-0.26
cd .worktree/backport-5292-to-release-0.26
git switch --create backport-5292-to-release-0.26
git cherry-pick -x cf98b9b61e25eae57fc9a50f1a320620d43d319d d0714e0828e3c8a538e474707fb4cb31f3ef0c95