Skip to content

[patch] [bugfix]: Bundle matching dSYMs in SPM integration artifacts - #3134

Open
josephpab wants to merge 2 commits into
devfrom
josephpab-msal-symbol-packaging
Open

josephpab wants to merge 2 commits into
devfrom
josephpab-msal-symbol-packaging

Conversation

@josephpab

@josephpab josephpab commented Oct 23, 2026 •

Copy link
Copy Markdown
Contributor

PR Checklist (must be completed before review)

  • All tests pass locally
  • PR size is <= 500 LOC per PR Size Check policy
  • PR is independently mergeable (no hidden dependencies)
  • Appropriate reviewers are assigned
  • PR reviewed by code owner (required if Copilot-generated)
  • SME or Senior IC assigned where required

Proposed changes

Relates to #3131. Register each existing archive's MSAL.framework.dSYM with its matching framework using xcodebuild -create-xcframework -debug-symbols. Request DEBUG_INFORMATION_FORMAT=dwarf-with-dsym for all existing archives, preserve POSIX sh compatibility and paths containing spaces, and retain the current three-slice default and optional five-slice visionOS validation.

Before ZIP/checksum generation, require every XCFramework slice to declare DebugSymbolsPath, contain its framework and dSYM DWARF binaries, and have identical per-architecture UUIDs matching SupportedArchitectures. Both affected SPM CI jobs run the lightweight regression suite and shell syntax check before integration packaging. The changelog records the integration-artifact change without claiming production artifacts have already changed.

Production dependency: This PR changes the public integration-test packager, not the production release packager. A companion release-pipeline change must also land before newly published MSAL.zip artifacts contain the matching dSYMs. This PR is independently mergeable as regression coverage, but does not by itself resolve #3131 or alter existing release artifacts. No SDK APIs, supported release platforms, dependencies, release versions, generated Package.swift, or binary artifacts are changed.

Type of change

  • Feature work
  • Bug fix
  • Documentation
  • Engineering change
  • Test
  • Logging/Telemetry

Risk

  • High – Errors could cause MAJOR regression of many scenarios. (Example: new large features or high level infrastructure changes)
  • Medium – Errors could cause regression of 1 or more scenarios. (Example: somewhat complex bug fixes, small new features)
  • Small – No issues are expected. (Example: Very small bug fixes, string changes, or configuration settings changes)

Additional information

Verified locally without running Xcode builds/tests/simulators or the side-effectful integration publisher:

  • PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -s scripts/tests -p 'test_*.py' -v: 11 tests passed; fixtures cover missing metadata/binaries, wrong UUIDs, missing/extra architectures, malformed UUID output, duplicate/missing slices, versioned macOS symlinks, UUID case normalization, CLI success/failure, and isolated shell argument assembly for both platform sets under a path with spaces.
  • sh -n spm-integration-test.sh and git diff --check: passed.
  • Both modified pipeline YAML files parsed successfully with Ruby's standard YAML parser.

CI evidence for head a6568fdbbc7c: The SPM integration job passed with real archives. Its logs confirm metadata-linked dSYM UUID validation for iOS device (arm64), iOS simulator (arm64, x86_64), and macOS (arm64, x86_64); inclusion of all three dSYM DWARF binaries in the generated ZIP; checksum generation; and a successful SwiftPM consumer simulator build. CodeQL, changelog, PR size, CLA, macOS validation, iOS Native Auth E2E, and Broker submodule checks also passed.

Current CI blockers: Overall PR validation failed in unchanged tests: the iOS suite has a Safari callback expectation timing out after 0.5 seconds; macOS Native Auth E2E reports OTP/callback failures and email-provider throttling (HTTP 429). No packaging failure was observed. These failures have not been bypassed, and the full suite is not claimed green.

Remaining acceptance gates: visionOS CI only runs on the existing release/main trigger paths. The successful sample simulator build is not proof of symbol propagation into an app archive. Before accepting the production fix, archive iOS-device and macOS consumer apps using the generated SwiftPM artifact and confirm their archives contain matching MSAL dSYMs without custom copy scripts; also validate the final signed production ZIP and recalculated checksum. Those visionOS/consumer-archive/production checks remain unverified.

Associate each existing XCFramework slice with its archive dSYM using absolute paths, validate metadata and architecture UUIDs before packaging, and cover the contract in both SPM CI jobs.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
@josephpab
josephpab requested review from a team as code owners October 23, 2026 17:13
@josephpab
josephpab requested review from agubuzomaximus and galwarsamy and a balanced review from Copilot October 23, 2026 17:13
Reference #3134 without implying the production release artifact has already changed.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔵 Needs a closer look

Compatibility with real Xcode artifacts and Apple’s dwarfdump remains pending CI or maintainer confirmation for both platform configurations.

No open issues 🎉

What changed in this PR

This PR adds matching dSYMs to MSAL’s Swift Package Manager integration-test artifacts, providing regression coverage related to #3131. Production release packaging remains a separate change; this PR does not update published artifacts or SDK APIs.

Changes:

  • Generate and bundle dSYMs for the default three slices and optional five-slice visionOS configuration.
  • Validate symbol metadata, binaries, architectures, and UUID matches before ZIP and checksum generation.
  • Add regression tests and run them alongside shell syntax checks in both affected CI jobs.
File Description
spm-integration-test.sh Bundles each framework’s dSYM and validates symbols before packaging.
scripts/​validate_xcframework_dsyms.py Checks per-slice metadata, binaries, architectures, and UUID matches.
scripts/​tests/​test_validate_xcframework_dsyms.py Covers validation failures, supported layouts, and shell argument handling.
azure_pipelines/​visionos-validation.yml Adds regression tests and shell syntax validation to visionOS CI.
azure_pipelines/​pr-validation.yml Adds regression tests and shell syntax validation to standard SPM CI.

Review effort: Balanced

Copilot AI balanced review requested due to automatic review settings October 23, 2026 17:15

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔵 Needs a closer look

Human approval should confirm CI successfully packages real Xcode-generated XCFrameworks and validates their UUIDs using Apple’s tools.

No open issues 🎉

Review effort: Balanced

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Include dSYMs inside MSAL.xcframework in the SwiftPM MSAL.zip

2 participants