Fix BCR presubmit: declare apple_support and pin host deployment target

[dfed]

Summary

BCR presubmit (bazelbuild/bazel-central-registry#8711) failed in two ways. Both are well-trodden ground for BCR-published Swift modules — surveyed five of them and adopted the unanimously-used flags. This PR carries the substantive config fixes; the surrounding meta-changes (CI mirror attempts, retry-action workaround) are documented at the bottom.

Substantive fixes

Failure 1 — Build SafeDI targets (CC toolchain analysis error)

ERROR: ... in xcode_swift_toolchain rule ...
Invalid target triple: local, this likely means you're using the wrong CC toolchain,
make sure you include apple_support in your project

rules_swift's xcode_swift_toolchain falls through to cc_toolchain.target_gnu_system_name, which returns the literal string "local" on BCR's runner because Bazel auto-detects a non-Apple-aware CC toolchain.

Fix (both belt and suspenders, both have prior art):

• bazel_dep(name = "apple_support", version = "1.24.2", ...) in root MODULE.bazel. Matches what swift-syntax, swift-index-store, and rules_xcodeproj all do — apple_support's bazel_dep registers a proper Apple-aware CC toolchain so the auto-detect fallback isn't reached.
• --repo_env=BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN=1 in .bcr/presubmit.yml build_flags. This is unanimous across all five BCR Swift modules I surveyed — it tells Bazel to skip CC auto-detection entirely, so the broken fallback can't run regardless of toolchain registration.

Failure 2 — Build downstream example (dyld at execution)

SafeDITool failed: ...
dyld: Library not loaded: /usr/lib/swift/libswift_DarwinFoundation2.dylib
  Referenced from: ... SafeDITool (built for macOS 26.0 which is newer than running OS)

SafeDITool gets compiled fresh under exec config with Xcode 26's SDK, which pins macOS 26 as the deployment target. BCR's runner has Xcode 26 installed but runs an older OS, so dyld refuses the binary.

Fix: Pin host and target deployment targets in .bcr/presubmit.yml build_flags and the corresponding .bazelrc files. Values match the actual support requirements rather than picking a single number for everything:

Flag	Where	Value	Why
--host_macos_minimum_os	everywhere	11.0	SafeDITool only needs to run, not exercise newer APIs. Lowest reasonable value — matches Package.swift's .macOS(.v11). Ensures the binary loads on whatever older macOS BCR's runner happens to be on.
--macos_minimum_os (root SafeDI)	root .bazelrc, verify_safedi_build BCR task	11.0	Matches Package.swift — what SafeDI as a library claims to support.
--macos_minimum_os (example app)	example .bazelrc, bcr_test_module.build_example BCR task	14.0	The example app's source requires it: LoggedInView's onChange(of:initial:_:) is macOS 14+, NameEntryView's TextField init is macOS 12+. The example app's deployment requirements are independent of SafeDI's.

Verified locally: otool -l SafeDITool reports minos 11.0 in LC_BUILD_VERSION. The flag actually takes effect in the binary, independent of runner OS. (Earlier iterations of this PR set the host target at 12.0 then 14.0 — both wrong: 12.0 was a guess, 14.0 was higher than Package.swift's claim.)

Prior art surveyed

Module	BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN	--macos_minimum_os	apple_support in MODULE.bazel	Tool runs during BCR test?
swift-syntax 603.0.1	✅	13.0	✅	No
swift-index-store 1.9.2	✅	12.0	✅	No
swift-filename-matcher 2.0.1	✅	—	✅	No
asc_swift 1.6.0	✅	—	✅	No
rules_xcodeproj 4.0.1	—	—	✅	No

Every flag we use has prior art — except --host_macos_minimum_os in .bcr/presubmit.yml build_flags. None of the surveyed modules execute their tool during the BCR test (they only build it). SafeDI is genuinely uncommon: our bcr_test_module.build_example task uses safedi_compile, which actually invokes SafeDITool, so dyld fires there. The --host_macos_minimum_os flag is the principled exec-config analogue of --macos_minimum_os — same flag family, same Bazel concept — but its specific use in BCR build_flags is our derivation, not directly observed elsewhere.

Confidence

Claim	Confidence	Why
apple_support + BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN fixes Failure 1	High	Unanimous across five surveyed BCR Swift modules.
--host_macos_minimum_os keeps SafeDITool runnable on older OS	Verified	otool -l confirmed minos 11.0 in LC_BUILD_VERSION, independent of host.
Deployment target values match actual support requirements	High	11.0 matches Package.swift; 14.0 for the example matches its actual API usage.
--host_macos_minimum_os belongs in BCR build_flags	Medium	Principled extension of --macos_minimum_os to exec config. No direct prior art because no surveyed module exec's a tool during BCR. Hard to raise without actually running on BCR's runner.
Local CI passing implies BCR will pass	Low	Established earlier — local CI can't reproduce BCR's environment. BCR remains canonical.

Why we didn't catch this in our CI, and why we're not going to chase it

Initially tried switching the bazel job to macos-15 to reproduce BCR's SDK-vs-runner-OS gap. The right way to actually mirror BCR is .bazelci/presubmit.yml on BuildKite — same infrastructure rules_swift / rules_apple use — but BazelCI is closed to non-bazelbuild projects that aren't rules. Any GH Actions mirror we hand-build will still drift from BCR's image (CC toolchain auto-detection, exact Bazel point release).

Reverted that switch. The bazel job stays on macos-26 as a general sanity gate, with build_targets aligned to .bcr/presubmit.yml so divergence is at least visible in review. BCR's presubmit is treated as the canonical macOS-on-older-OS check.

Note on the retry composite action

A first iteration tried to use a multi-line YAML | block scalar for the new explicit bazelisk build command. That broke .github/actions/retry/action.yml, which splices ${{ inputs.command }} straight into a bash loop and tacks && break onto the same source line — a multi-line command leaves && break orphaned. Fixed by keeping the command on a single line, with a comment in ci.yml explaining why.

Release note

These fixes ship in 2.0.0-rc-3. The existing BCR PR for 2.0.0-rc-2 is built from the published tarball and can't pick them up retroactively — it'll need to be replaced with a new submission targeting rc-3.

Test plan

• bazelisk build //Sources/SafeDI:SafeDI //Sources/SafeDICore:SafeDICore //Sources/SafeDIMacros:SafeDIMacros //Sources/SafeDITool:SafeDITool from repo root — passes locally
• (cd Examples/ExampleBazelIntegration && bazelisk build //Subproject:Subproject //ExampleBazelIntegration:ExampleBazelIntegration) — passes locally
• otool -l <SafeDITool> shows minos 11.0 — deployment-target flag verified in LC_BUILD_VERSION
• ./CLI/lint.sh — clean
• CI green
• After merge + 2.0.0-rc-3 release, replace BCR PR #8711 with one targeting rc-3 and confirm BCR presubmit passes

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (dc5ab3f) to head (8f16e1d).

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #295   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           41        41           
  Lines         7043      7043           
=========================================
  Hits          7043      7043           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.