Repository navigation
ci: skip the device test app in the macOS build and stop serializing verify-api and format-code - #5758
Merged
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5758 +/- ##
=======================================
Coverage 76.13% 76.13%
=======================================
Files 528 528
Lines 19579 19579
Branches 3829 3829
=======================================
Hits 14906 14906
Misses 3791 3791
Partials 882 882 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
ric-oliv
added a commit
that referenced
this pull request
Oct 21, 2026
device-test.ps1 picked a simulator in -Build too, though only xharness uses it. Now that the workflow boots the simulator while the app builds, that simctl call blocked for about 3 minutes on #5758's first run. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ric-oliv
force-pushed
the
ci/faster-pr-builds-round-2
branch
from
October 21, 2026 18:58
a6c8173 to
6ddf5e1
Compare
ric-oliv
marked this pull request as ready for review
October 21, 2026 20:11
jamescrosswell
left a comment
Collaborator
There was a problem hiding this comment.
Nice - thanks @ric-oliv !
Any specific reason to target version7 with this change? If not, maybe we could change the target to main before merging?
The macOS leg of build.yml built Sentry.Maui.Device.TestApp for net9.0-android, net10.0-android and net10.0-ios, and nothing in build.yml runs it. In the run for #5752 on version7 that was the last 6 minutes of the 24.7-minute Build step, on the critical path. The Linux and Windows filters already exclude the app, and both device test workflows build it themselves. The macOS leg of verify-api builds the same filter, so it no longer builds the app either. The device test path filters now also cover what the app compiles and they didn't list: Sentry.Analyzers, Sentry.Testing.CrashableApp, the nested Directory.Build files and .editorconfig, which can fail the build because warnings are errors. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Both workflows put the whole run in the pr-auto-commit concurrency group, so each waited for the other to finish. On one PR, format-code started 35 minutes after its run was created, and on another verify-api waited 13 minutes. The group exists to keep their git pushes apart, so it now covers only accept-api-changes and the format-code job, and the API test matrix starts right away. Both still push from the head they checked out and fail as non-fast-forward if the branch moved in the meantime. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ric-oliv
force-pushed
the
ci/faster-pr-builds-round-2
branch
from
October 22, 2026 08:06
6ddf5e1 to
aa12ec7
Compare
Member
Author
|
Good point, no reason. Changed to main! |
jamescrosswell
approved these changes
Oct 22, 2026
jamescrosswell
left a comment
Collaborator
There was a problem hiding this comment.
Nice - thanks @ric-oliv !
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.
This follows up on #5746. On #5752, the first
version7PR after it, the build workflow took 63.3 minutes, and the macOS.NETjob took 59.6 of those. This PR makes two more cuts, and no test is dropped. The device tests now also run for a few changes they used to skip.I first opened it against
version7and measured it there, on top of #5746. Neither change depends on #5746, so it now targetsmain.Sentry-CI-Build-macOS.slnfno longer includesSentry.Maui.Device.TestApp. The macOS build job compiled it for net9.0-android, net10.0-android and net10.0-ios (net10.0-android, net11.0-android and net11.0-ios onversion7), and nothing inbuild.ymlruns it. In chore(samples): move the Azure Functions sample to Azure.Functions.Sdk and net11.0 #5752's run onversion7, packaging that app was all the Build step did after minute 18.4 of 24.7, and in a recentmainrun it took the last 8 minutes of 35. The Linux and Windows filters already exclude it, and both device test workflows build it themselves. Onmain, the macOS leg ofverify-apibuilds the same filter, so it stops building the app too.dotnet testskips it because platform TFMs aren't test projects here,dotnet packskips it because it isn't packable, and the sparse checkout deletes itsbinandobjbefore the integration tests. So all it gave us was a compile check, and both device test workflows already run one withscripts/device-test.ps1 -Build. Every project it depends on still builds for its mobile TFMs, and the job packs the same packages as before.Sentry.Analyzers,Sentry.Testing.CrashableApp, the nestedDirectory.Build.*files and.editorconfig, which can fail the build because warnings are errors.version7, both filters also needsrc/Sentry.Extensions.Hosting/**, since feat: add Sentry.Extensions.Hosting with UseSentry for generic host apps #5739 madeSentry.Maui.Testsreference it. That project isn't onmain, so I left it out here. It needs adding whenmainnext merges intoversion7.verify-apiandformat-codeshared thepr-auto-commitconcurrency group at workflow level, so each waited for the other to finish. On one PR, format-code started 35 minutes after its run was created, and on another verify-api waited 13 minutes. The group exists to keep their git pushes apart, so it now covers onlyaccept-api-changesand theformat-codejob.Here's the CI run on
main, compared with the medians ofmainPR runs since October 15, which are 26 build runs and 14verify-apiruns:mainPRs, medianmain.NETjob.NET (win-x64)jobverify-apimacOS jobUnsupported AOT (win-x86), which waits on every leg, spent 8 minutes in setup on this run.mainPR and packed the same 53 packages.format-codewas done after 12.5 minutes instead of waiting for the API tests, and the device tests passed.Here's what the build workflow took on three CI runs of this PR while it targeted
version7, compared with #5752:.NETjob.NET (win-x64)jobSo on
version7this PR saves about 7 minutes on every build workflow run. Runs 2 and 3 took 56.4 and 56.7 minutes, 6.6 to 6.9 minutes under #5752. Run 1 barely moved because that runner spent 4.5 minutes downloading one workload pack during setup and ran the tests 2.4 minutes slower.verify-apiandformat-coderan side by side, and both were done within 12.6 to 15.6 minutes of the push in all three runs. The API commit job still waits for the format job, as intended.version7. All 2997 iOS device tests and 8 iOS integration cases passed as well.With macOS down to about 49 minutes on
version7and 53 onmain,.NET (win-x64)is now the slowest leg on both, at 53 to 56 minutes. So the next round of CI work should focus on the Windows jobs. Their Test step alone takes 16 to 21 minutes, and in #5752's run only about 8 of those were spent inside the tests themselves.The first two runs also included an iOS change that I've since taken out: booting the simulator while the device test app builds. It cut the app install from 6 min 46 s to under 20 seconds, but the app build got slower by about the same amount, so the iOS job didn't get faster. The build workflow doesn't use either of the files it touched, and run 3 ran without it.
Craft releases aren't affected. The device tests still run on every push to
mainandrelease/*, the macOS job still uploads the commit-SHA artifact with the same packages, and no check names change.#skip-changelog