Odd concurrency issue where GitHub commit links to different Cirrus CI pipelines

[kratsg]

Expected Behavior

What should have happened is that all jobs for a given Cirrus CI pipeline are linked correctly to the corresponding commit.

Real Behavior

What ended up happening was not clear. I'm still not quite sure what's going on so I'll link below.

Related Info

This is a (tick one of the following):

• Website issue
  • Link to page:
• Task issue
  • OS: (Docker, macOS, Windows, FreeBSD)
  • Task name:
  • Script/cache name (if applies):

Neither a website issue or task issue -- probably related to how Cirrus CI and GitHub are communicating between themselves. See below for more details.

---

In kratsg/pylibmagic, I need to build aarch64/arm64 wheels (cross-compile) using cibuildwheel. If you view the jobs on this commit: kratsg/pylibmagic@1cdc904, you'll see three checks from Cirrus:

which link to:

• https://github.com/kratsg/pylibmagic/runs/13593700507
• https://github.com/kratsg/pylibmagic/runs/13593700351
• https://github.com/kratsg/pylibmagic/runs/13593700500

However, if you go to the individual pages here, you'll see they are built from different sources (two of them from the main branch and one of them from the v0.4.0 branch)! I'm not sure how this happened, but it's likely a concurrency issue that I'm not clear on how to fix so easily beyond just... tagging after bumping up my versions (I rely on your-tools/tbump here).

In fact, I have two separate pipelines here on Cirrus:

• https://cirrus-ci.com/build/4638941672898560 (main branch)
• https://cirrus-ci.com/build/6516162154987520 (v0.4.0 branch)

and I suspect it's truly just a race condition, but I'm a bit surprised that it's breaking the linkage of the runs on GitHub. The reason is I rely on being able to find the corresponding runs from Cirrus CI to be able to download the artifacts back into GitHub to collect with other wheels I'm building in GitHub actions and release/deploy to pypi afterwards... so I need to have the right runs linked correctly in GitHub (as I rely on GitHub API here for figuring out the correct jobs).

[fkorotkov]

Hey @kratsg, unfortunately it's a caveat of GitHub API. Specifically that we can only set SHA basis and not on a more specific ref.

In your case the main branch and v0.4.0 tag were updated within a second of each other so two builds that you linked raced to finish. Status that you see on the check runs are the representing results of the last fished task chronologically speaking.

Unfortunately I don't think there is anything we can do because it's not clear what is the expected behaviour should be give the API limitation.