Run the compiler validation suite for Android #8
Conversation
|
Aah, got much further with the clang package, that shaved 1 hour off the build. 🎆 Add the |
|
Can't read some of the failing logs, I think those runners ran out of disk space and it couldn't extract them. For the docker runs, you can probably delete all of |
Do you mean by applying https://patch-diff.githubusercontent.com/raw/swiftlang/swift/pull/81398.patch to I can try to coerce it manually, unless you know of an easier way? |
|
Remove the |
|
That reduced the number of failures for the 6.2 branch from 90 (https://github.com/swift-android-sdk/swift-docker/actions/runs/15475430398/job/43569489696): 90 failures77 failures |
|
There's only 2 failures on development (https://github.com/swift-android-sdk/swift-docker/actions/runs/15495418271/job/43630847776): 2 failures |
|
Looks like you'll need swiftlang/swift#81312 for 6.2 also, plus some additional tweaks for the last 2-3 failing tests, will look at those. |
|
OK, strangely you will need swiftlang/swift#81643 also for 6.2, those two pulls should get 6.2 passing the compiler validation suite. I will roll up all the 6.2 commits we need into an upstream pull and submit it later.
These are not reproducible on the community Android CI or 6.2, so they appear to be trunk regressions related to Docker? Reverting swiftlang/swift@a65912f09 in 6.3 alone should fix the first one, whereas I have no idea about that new trunk crasher test only failing in Docker: simply patch it with |
OK, but I won't be able to work on it until Tuesday at the earliest, so if you want to give it a shot before then, you can update the patch at https://github.com/swift-android-sdk/swift-android-sdk/blob/main/swift-android-devel-pr81398.patch 1 and re-run the swift-docker action (https://github.com/swift-android-sdk/swift-docker/actions/workflows/pull_request.yml) to see what happens. Footnotes
|
|
I'm unable to push to this repo: |
|
Alright, we're in pretty good shape at this point: it simply keeps timing out because it takes forever to build the host Swift compiler for some reason, with 75+% of the six-hour github free time limit eaten up just for that! I'm going to move on to upstreaming patches and integrating the NDK CMake toolchain file, which we'll need when we re-enable libTesting again too. Three things you might want to look at:
This mostly works now, just need to clean it up and run it to completion, maybe locally if nothing else. |
Yeah, I was just thinking that maybe I should try setting up a self-hosted runner for this, which at least won't time out. I'll look into it later today. |
|
I'm working on getting this back up to date and get at least one of the build variants green, as well as enable a self-hosted runner that can hopefully get around the 6-hour time limit so we can get a full compiler validation build running to completion. There are a couple new problems. On the 6.2 branch, there's a failure applying and on trunk, there's a different failure: These seem to be new as of last night, which seems to be why https://github.com/finagolfin/swift-android-sdk/actions passed. |
|
Looks like some upstreamed patches have hit the source snapshots finally, so I will update my patches upstream. You'll need to rebase your patches then and remove that failing Also, we know the AArch64 compiler validation suite passed, but I suspect armv7 won't. So change the order to build that SDK arch first, then x86_64, and AArch64 last in this build script, so we can fail fast if we need to fix that too. |
|
Alright, updated my patches, you can rebase. You should also stop applying my |
|
We're getting close. Self-hosted had only one test failure: |
|
OK, and that too only because you accidentally reverted one of the Docker patches when you rebased and the other compiler crasher I disabled before now strangely works. I notice that it's still building aarch64 first, as the bash loop probably always runs alpabetically on the passed-in words. I will update that patch and kick off another build. |
…ork, and comment out self-hosted till we know armv7 works
I don't see how that could be happening (the script just does
Did you mean to disable the |
|
I also added back the two non-compiler-validation docker builds to the matrix. I want to keep running those to ensure that everything else is working, and I'm also using the bundle artifacts that they create for additional (out of band) testing. They are relatively quick to run and don't otherwise interfere with the compiler validation builds, so I don't see any harm in keeping them going. |
You were right, that wasn't the issue. The issue is we didn't read the code closely, as that was just the default set of arches we were modifying. The actual arches are set here and override the defaults when passed in to
Yes, I figured all would fail on armv7, so I didn't want to waste self-hosted runs to get the same data I would get from the github runners.
I figured those added no value since they always complete successfully now, and we won't be using anything but the SDKs from the compiler validation builds from now on. The longer 12-hour timeout you just added also wasn't enough, as the self-hosted compiler build was even slower, now taking almost 8 hours. Kicking off another pair of non-self-hosted builds just to check armv7 and once any issues there are fixed, we can try self-hosted again with a 15-hour timeout. |
There is still value to a fast-track (i.e., non compiler-validated) option for the SDK generation. For example, if we want to iterate on getting 16kb page size compatible SDKs built and tested, being able to get that done in ~1h:30m is a lot better than 6h+.
The self-hosted machine is the same one that is simultaneously running the Swift Android Community CI, and the most recent runs of that have gone from ~5h to ~10h, so the machine is probably overwhelmed. I can disable the community CI temporarily if we want to see if it helps? |
Oh, of course, I just disabled those temporarily here while I iterate on the full compiler-validated builds in this pull. Do whatever you like once I get those working. 👍
Sounds good, I will let you know when I kick off another self-hosted run later today and then maybe you can temporarily switch off the community CI runners. The good news is that once we get this Docker pull in upstream, we can turn off the community CI permanently. 😃 |
…with the armv7 stdlib and tests
|
armv7 finally finished after 12h: I've temporarily disabled the community Swift CI, so future self-hosted runs should be a bit faster until I re-enable it. |
Uh oh!
There was an error while loading. Please reload this page.