[xcode26.6] Bump to Xcode 26.6 Release Candidate 2#25744
Conversation
There was a problem hiding this comment.
Pull request overview
Updates the repository’s build configuration to use Xcode 26.6 Release Candidate 2, ensuring local/CI builds target the intended Xcode RC for this release branch.
Changes:
- Updated the Xcode download URL to the RC2
.xip. - Updated
XCODE_DEVELOPER_ROOTto point to the RC2 app bundle name.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
The simulator test stage (tools/devops/automation/templates/tests/build.yml) ran the "Enable Xamarin and configure platforms" step (./configure --xcode=$(xcode-select -p)) *before* "Provisionator dependencies". On a bot whose default xcode-select differs from the Xcode we build against (e.g. during an Xcode beta bump), this captured the wrong Xcode and wrote it as XCODE_DEVELOPER_ROOT into configure.inc. Make.config -includes configure.inc and system-dependencies.sh sources it, so that stale path overrode the correct Make.config XCODE_DEVELOPER_ROOT default. As a result "Provision system dependencies" (check-system) and the make-based test build both used the wrong Xcode -- failing with "You must install Xcode <X> ... (found <Y>)" and leaving the target simulator runtime unprovisioned. Move the configure step to run after "Provisionator dependencies" (and before "Provision system dependencies"), mirroring the build stage (build/build.yml), so configure.inc captures the Xcode that Provisionator just selected. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> (cherry picked from commit 5319ba5) Co-authored-by: dalexsoto <204671+dalexsoto@users.noreply.github.com>
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
… stage" This reverts commit 94be712. Co-authored-by: dalexsoto <204671+dalexsoto@users.noreply.github.com>
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Add a configure-time option for selecting the Xcode installation used by
the build.
Some build images install Xcode 26.5 as:
/Applications/Xcode_26.5.app
while the repository default points at:
/Applications/Xcode_26.5.0.app
Xcode does not behave well when accessed through symlinks, so make the
path explicit instead of requiring machines to provide an alternate app
bundle name.
The configure options accept either the Xcode app bundle path or the
developer root path:
./configure --xcode=/Applications/Xcode_26.5.app
./configure --xcode=/Applications/Xcode_26.5.app/Contents/Developer
./configure --xcode-root=/Applications/Xcode_26.5.app
./configure
--xcode-developer-root=/Applications/Xcode_26.5.app/Contents/Developer
Based on PR review feedback, `configure` now writes the selected path
directly to `configure.inc` as `XCODE_DEVELOPER_ROOT`. `Make.config`
includes `configure.inc` before resolving the Xcode block and uses `?=`
for the existing default path:
XCODE_DEVELOPER_ROOT?=/Applications/Xcode_26.5.0.app/Contents/Developer
This keeps the behavior simple and consistent with the other configure
options: an explicitly configured Xcode path wins, while the existing
`.0.app` path remains the default when no path is configured.
`system-dependencies.sh` now also checks `configure.inc` for
`XCODE_DEVELOPER_ROOT` before falling back to the `Make.config` default,
and direct invocations export `DEVELOPER_DIR` from the resolved Xcode
root so the script and Make agree on the selected Xcode.
No pipeline- or agent-specific logic is added. CI can opt into the
shorter app bundle name by running:
./configure --xcode=/Applications/Xcode_26.5.app
Local developers with `Xcode_26.5.0.app` can continue using the default
configuration unchanged.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
(cherry picked from commit dbc04b5)
Move the CI build/test/API-diff flows to the ACES shared macOS pool while keeping PR validation on the existing PR pool for now. This PR enables ACES for the CI entry points only: - `build-pipeline.yml` - `run-ci-api-diff.yml` - `run-post-ci-build-tests.yml` The PR entry points remain opt-out for now and can be flipped later once CI is stable: - `build-pull-request.yml` - `run-pr-api-diff.yml` - `run-post-pr-build-tests.yml` - Added/used the `useACES` template parameter to route CI build, API diff, and simulator-test jobs to the ACES shared pool/image. - Kept the existing non-ACES pool and demand behavior when `useACES` is false. - Marked ACES simulator-test jobs with `VM_VENDOR=ACES` so tests that should not run on virtualized machines can opt out correctly. - Avoid deleting simulator runtimes on ACES, since that operation is not supported/reliable there. - Wait longer for non-x64 simulator cleanup to complete before continuing. - Skip x64 simulator test runs on ACES machines. - Use the Xcode selected by `xcode-select` for build configuration and pre-configure provisioning, so ACES agents with `/Applications/Xcode_26.5.app` do not require symlinks or the traditional `/Applications/Xcode_26.5.0.app` bundle name. - Harden the `System.Net.Http` monotouch tests against transient CI/httpbin network timeouts so network stalls do not hang the entire monotouch app until the harness timeout. This branch includes the configure support from #25622. The CI templates use the selected Xcode developer root so both classic bots and ACES images can configure/build with the Xcode that is actually installed on the agent. The original green build links in this PR description became stale as the branch evolved. Recent follow-up failures were investigated and resulted in the Xcode selection and network-timeout fixes included here. The intended validation matrix is: - CI Build on ACES - CI API diff on ACES - Post-CI simulator tests on ACES - PR pipelines still using the existing PR pool --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com> (cherry picked from commit 4d39e1b)
…25684) The simulator test stage (tools/devops/automation/templates/tests/build.yml) ran the "Enable Xamarin and configure platforms" step (./configure --xcode=$(xcode-select -p)) *before* "Provisionator dependencies". On a bot whose default xcode-select differs from the Xcode we build against (e.g. during an Xcode beta bump), this captured the wrong Xcode and wrote it as XCODE_DEVELOPER_ROOT into configure.inc. Make.config -includes configure.inc and system-dependencies.sh sources it, so that stale path overrode the correct Make.config XCODE_DEVELOPER_ROOT default. As a result "Provision system dependencies" (check-system) and the make-based test build both used the wrong Xcode -- failing with "You must install Xcode <X> ... (found <Y>)" and leaving the target simulator runtime unprovisioned. Move the configure step to run after "Provisionator dependencies" (and before "Provision system dependencies"), mirroring the build stage (build/build.yml), so configure.inc captures the Xcode that Provisionator just selected. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> (cherry picked from commit 586814a)
The xamarin-macios-sim-pr-tests pipeline (run-post-pr-build-tests.yml) fails on the traditional PR pool: xharness cannot create the simulator device types during task population, aborting every simulator test leg. Flip useACES to true so PR simulator tests run on the ACES shared pool / image (a clean VM without the extra Xcodes installed on the traditional bots), to test whether that resolves the simulator device-type failure. This relies on the ACES infrastructure backported in #25622, #25572 and #25684. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Keep the routing table in variables/common.yml in sync with the run-post-pr-build-tests.yml flip so the documented PR/CI ACES state isn't contradictory. Narrator: Alex also contributed to this change by taking the initiative to test ACES everywhere ;) ;) ;) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
🔥 [CI Build #176286e] Test results 🔥Test results❌ Tests failed on VSTS: test results 5 tests crashed, 0 tests failed, 142 tests passed. Failures❌ Tests on macOS Monterey (12) tests🔥 Failed catastrophically on VSTS: test results - mac_monterey (no summary found). Html Report (VSDrops) Download ❌ Tests on macOS Ventura (13) tests🔥 Failed catastrophically on VSTS: test results - mac_ventura (no summary found). Html Report (VSDrops) Download ❌ Tests on macOS Sonoma (14) tests🔥 Failed catastrophically on VSTS: test results - mac_sonoma (no summary found). Html Report (VSDrops) Download ❌ Tests on macOS Sequoia (15) tests🔥 Failed catastrophically on VSTS: test results - mac_sequoia (no summary found). Html Report (VSDrops) Download ❌ Tests on macOS Tahoe (26) tests🔥 Failed catastrophically on VSTS: test results - mac_tahoe (no summary found). Html Report (VSDrops) Download Successes✅ cecil: All 1 tests passed. Html Report (VSDrops) Download macOS testsLinux Build VerificationPipeline on Agent |
…igured Xcode The generated, gitignored root Build.props carries the XCODE_<ver>_PREVIEW NoWarn, but only when the selected Xcode is a preview (XCODE_IS_STABLE=false). It is generated as a side effect of the `-include dotnet.config` remake on any make invocation. On a clean workspace an early `make` can run before `./configure`: the CI "Generate provisionator files" step exports XCODE_DEVELOPER_ROOT from whatever Xcode happens to be selected on the bot (a stable Xcode), which overrides the `?=` default in Make.config, so Build.props is generated with XCODE_IS_STABLE =true and without the NoWarn. `./configure` then writes the correct (preview) Xcode into the separate configure.inc, but because Build.props only depended on Make.config (whose mtime is unchanged) it was never regenerated. The stale, NoWarn-less Build.props was then used for the whole build, causing thousands of XCODE_*_PREVIEW experimental-API errors in the in-place mac test app builds on clean workspaces (e.g. the ACES pool). Reused workspaces happened to keep a correct Build.props from a previous build, which masked the bug. Add configure.inc as a prerequisite of Build.props so it is regenerated once `./configure` has selected the real Xcode. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
✅ [PR Build #c2988cb] Build passed (Detect API changes) ✅Pipeline on Agent |
|
🔥 Failed to compare API and create generator diff 🔥 Error: The system requirements for the hash to compare against (a6c88b7�(B) are different than for the current hash. Comparison is currently not supported in this scenario.�(B Pipeline on Agent |
🔥 [PR Build #c2988cb] Build failed (Build macOS tests) 🔥Build failed for the job 'Build macOS tests' (with job status 'Failed') Pipeline on Agent |
✅ [PR Build #c2988cb] Build passed (Build packages) ✅Pipeline on Agent |
No description provided.