Repository navigation
Conversation
The Unsupported AOT jobs waited for the whole build matrix to use the macOS packages, but any leg's packages work. Every leg already packs and runs aot.Tests.ps1 against its own. linux-arm now runs in the linux-arm64 leg and win-x86 in the win-x64 leg, which removes two jobs and the tail after the matrix. Some arm64 hosts can't run 32-bit ARM binaries and failed with "Exec format error", so QEMU runs them on every host. The leg also logs whether its host runs them natively. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A registered QEMU handler doesn't prove it ran the binary. A 32-bit ARM process sees armv8l when the arm64 kernel runs it and armv7l under QEMU, so the leg compiles a tiny uname program, logs what the host does natively, and fails unless QEMU runs it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5791 +/- ##
==========================================
- Coverage 76.13% 76.12% -0.02%
==========================================
Files 528 528
Lines 19579 19579
Branches 3829 3829
==========================================
- Hits 14906 14904 -2
- Misses 3791 3792 +1
- Partials 882 883 +1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
On the arm64 kernel, a 32-bit ARM process sees aarch64, not armv8l. It only sees armv8l when it starts in 32-bit mode through linux32. The check still holds, because only QEMU reports armv7l. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The two Unsupported AOT jobs check that Sentry turns SentryNative off on runtimes that have no native SDK, linux-arm and win-x86. They wait for the whole build matrix, because they test the macOS leg's packages. On #5788 they started 14 minutes after macOS had uploaded those packages, as soon as the slowest leg finished, and added 1.5 minutes after the matrix.
They don't need the macOS packages, though. Every leg already packs its own and runs the same
aot.Tests.ps1against them in its integration tests. The macOS artifact was simply the package that was around when #4347 added the jobs.This PR runs the test inside the legs instead:
ubuntu-24.04-armrunner.windows-latestlike the old job.unsupported-aotjob is gone, and so is the tail after the matrix.The linux-arm job also had a flake. 4 of the last 57 attempts failed, and the one whose log was still around failed with "Exec format error". The test app built, but the host couldn't start a 32-bit ARM binary, and the same commit had passed on its first attempt. Some arm64 hosts can't run 32-bit ARM code, so the test no longer depends on the host:
docker/setup-qemu-action, pinned like inalpine.yml. QEMU then runs the test app and its container on every host.aarch64when the arm64 kernel runs it andarmv7lunder QEMU. The leg compiles a tinyunameprogram, logs what the host does natively next to itsCPU part, and fails unless QEMU runs it. So every run proves the QEMU path, and the log tells us which hosts caused the flake.On today's
main, win-x86 adds about 1.3 minutes to win-x64, which is one of the slowest legs until #5782 lands.Measured on the first run:
Aotpassed in 14.7 seconds andContainerin 16.3, both under QEMU.CPU part 0xd49, and it ran 32-bit ARM natively, printingaarch64. So the flaky hosts are a different CPU, and the next one will show up in this log.Aotpassed andContainerwas skipped, as in the old job, because it only runs on Linux.#skip-changelog