fix(uniffi): unblock publish workflow + polish output#1091
Open
pblazej wants to merge 9 commits into
Open
Conversation
The CodeQL autofix landed in #1078 added `permissions: contents: read` at the top level of uniffi-packages.yml, which then forbids any nested job (including the called workflow uniffi-swift.yml) from requesting higher permissions — workflow validation fails with: Error calling workflow ... The nested job 'build-and-publish' is requesting 'contents: write', but is only allowed 'contents: read'. Neither job actually needs write: `gh release list` in resolve-tag is read-only, and the publish step authenticates to the hosting repo with UNIFFI_XCFRAMEWORK_PAT (not GITHUB_TOKEN). Drop the elevation on both so the workflow can start.
pblazej
force-pushed
the
blaze/fix-workflow-permissions
branch
from
d78bf92 to
a60f3a8
Compare
cargo-make 0.37.25+ adds its own --force when running install_crate, so the explicit --force here makes cargo install reject the duplicate argument with exit 105.
Contributor
No changeset foundThis PR modifies the following packages but doesn't include a changeset: Directly changed:
Click here to create a changeset The link pre-populates a changeset file with If this change doesn't require a version bump, add the |
LiveKit's feature/framework-wrapping branch (PR #96 against antoniusnaumann/cargo-swift) has been merged upstream. Point at the upstream merge commit fe7becf so the fork dependency goes away.
Multi-arch xcframework build is the long pole. -xlarge is arm64 + paid; expect roughly half the wall-clock of the default macos-26 runner.
pblazej
changed the title
Dedent the if/elif/else/endif tags to column 0 and use {%- consistently
so the rendered Package.swift no longer emits a blank line between
.target and .binaryTarget. Verified locally — diff against the existing
hosting-repo manifest now shows only the intended version/checksum
changes.
Add the built PrivacyInfo.xcprivacy to the publish files list so the
hosting repo's copy stays in sync if the source manifest ever changes
(today it's identical, but the workflow shouldn't depend on that).
pblazej
commented
May 15, 2026
| build-and-publish: | ||
| name: Build & publish Swift xcframework | ||
| runs-on: macos-26 | ||
| runs-on: macos-26-xlarge |
Contributor
Author
There was a problem hiding this comment.
It seems it leverages the cache heavily now.
Contributor
Author
There was a problem hiding this comment.
Maybe we can switch to https://namespace.so/docs/architecture/compute/macos
Inject CARGO_PROFILE_RELEASE_DEBUG=limited and CARGO_PROFILE_RELEASE_SPLIT_DEBUGINFO=packed into the swift-xcframework task only, gated on the cargo-make release profile. Cargo treats them as [profile.release] overrides during this build, so dsymutil emits a sidecar .dSYM next to each per-arch dylib at target/<arch>/release/deps/liblivekit_uniffi.dylib.dSYM (~8.5 MB each, ~94 MB across the 11 Apple targets). Scoping via env vars keeps the workspace Cargo.toml profile lean — FFI, node, and Linux/Windows/Android release builds stay stripped and debug-info-free. limited (line tables + types) is ~3× smaller than full. Verified locally with a clean rebuild.
pblazej
changed the title
pblazej
commented
May 15, 2026
| # Linux/Windows/Android) remain on the lean Cargo.toml profile. | ||
| # `split-debuginfo = "packed"` triggers dsymutil → produces .dSYM bundles next | ||
| # to each per-arch .dylib at target/<arch>/release/deps/lib<name>.dylib.dSYM. | ||
| CARGO_PROFILE_RELEASE_DEBUG = { value = "limited", condition = { profiles = ["release"] } } |
Contributor
Author
There was a problem hiding this comment.
Wdyt @ladvoc?
It's not integrated into cargo-swift yet (needs another patch) but would be good to have, especially during initial adoption.
I confirmed it works locally.
Contributor
Author
There was a problem hiding this comment.
We can also tackle that in a separate PR.
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
1 participant
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.
Follow-up fixes surfaced while validating the publish pipeline against livekit/livekit-uniffi-xcframework#12.
Workflow
contents: write(blocked startup after the CodeQL autofix in UniFFI: Publish Swift packages #1078)--forcearg now that cargo-make adds its ownantoniusnaumann/cargo-swift@fe7becf— fork retired)macos-26-xlargefor ~½ wall-clockBuild output
Package.swiftto swift-tools 6.0.binaryTargetPrivacyInfo.xcprivacyin the publish setCARGO_PROFILE_RELEASE_{DEBUG=limited,SPLIT_DEBUGINFO=packed}into the swift-xcframework task so each per-arch dylib gets a sidecar.dSYM(~8.5 MB × 11 targets, ~94 MB raw) without touching the workspace's lean Cargo.toml profileDocs
AGENTS.md → README.mdAfter merge: re-dispatch
UniFFI packageswithdry_run=falseon a fresh test version to confirm end-to-end.