You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
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).
The text was updated successfully, but these errors were encountered:
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.
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):
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:
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 thev0.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:
main
branch)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).
The text was updated successfully, but these errors were encountered: