[CI] Check semver compatibility with all target platforms, not just the host platform

[joshlf]

We use cargo-semver-checks-action in CI to ensure we do not accidentally break semver compatibility: https://github.com/google/zerocopy/blob/0ff2dd15c958ab615b8094cf273f6b37d113c8fa/.github/workflows/ci.yml#L244-L264

This check occurs within our build matrix, so it's re-run for each target: https://github.com/google/zerocopy/blob/0ff2dd15c958ab615b8094cf273f6b37d113c8fa/.github/workflows/ci.yml#L41-L53

However, we aren't actually making use of target, meaning we are re-running the exact same check 11 times on the Github Actions host target (x86_64-unknown-linux-gnu).

We need to modify this CI job to respect the value of target. To do this, see here: https://github.com/obi1kenobi/cargo-semver-checks-action/issues/54#issuecomment-1711833826

[Sh0g0-1758]

Hello, @joshlf @jswrenn . Can you please assign me this issue. I am interested in working on this.

[joshlf]

Thanks @Sh0g0-1758! Assigned.

[memark]

I've started looking into this. I made some additional comments in the linked issue https://github.com/obi1kenobi/cargo-semver-checks-action/issues/54

I basically see three ways forward here:

• get cargo-semver-checks-action to add a pass-thru property in the form of target
• not use the action; install, build and run cargo semver-checks --target ourselves
• add a .cargo/config file with [build] target = ... to the downloaded repo before running the action (I only tried this briefly, but the file at least appears to be respected.)

[joshlf]

Based on https://github.com/obi1kenobi/cargo-semver-checks-action/issues/54#issuecomment-2200279212, I think that a PR to cargo-semver-checks-action is the way to go. If that turns out to be unexpectedly difficult, it wouldn't be a huge deal for us to just use cargo semver-checks --target directly. Thanks for investigating this!

[memark]

Update: My PR in that repo was merged today. I'll have a look at the associated cache key bug as well, and then I'll come back to finally solve this issue.

[joshlf]

Amazing, thank you for that!! It turned out to be a one-line change on our side, so I went ahead and implemented it: #1523

Thanks for unblocking this!

[memark]

Glad I could help!

(As mentioned, there is still a chance that we're running into a caching issue in that action with different targets, but I'll get to that shortly.)

[joshlf]

(As mentioned, there is still a chance that we're running into a caching issue in that action with different targets, but I'll get to that shortly.)

Sounds good! For performance reasons, we only run a subset of tests when a PR is pending (we run the full set of tests in the merge queue), so it's possible that when we try to merge https://github.com/google/zerocopy/pull/1523, that bug will crop up. Fingers crossed...