feat: swift package release workflow#395
Merged
Merged
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughThe release and packaging flow now computes shared version values, builds iOS and visionOS artifacts, stamps packaged templates, switches project templates to SwiftPM-delivered frameworks, publishes release assets, and updates and verifies the ios-spm manifest. ChangesSwiftPM release packaging
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Nitpick comments (1)
.github/workflows/npm_release.yml (1)
371-413: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick winExtend the SPM smoke test to cover visionOS artifacts too.
The release publishes visionOS zips/checksums, but this probe only resolves the iOS product. A bad visionOS checksum or missing asset would still pass the workflow.
Before wiring this in, verify the visionOS product/target names in
ios-spm/Package.swift; then add a second probe target/platform that forces SwiftPM to resolve the visionOS binary targets.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/npm_release.yml around lines 371 - 413, The SPM smoke test only exercises the iOS binary resolution, so a broken visionOS artifact could still slip through. Update the verify-spm job to also resolve the visionOS package by adding a second probe target/platform in the Generate a probe package step, and make sure the visionOS product/target names match those declared in ios-spm/Package.swift so SwiftPM is forced to fetch and checksum-validate the visionOS zips as well.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/npm_release.yml:
- Around line 20-31: Pin the workflow’s GITHUB_TOKEN permissions for the
remaining jobs so they only have repository read access, since `setup`,
`spm-update`, and `verify-spm` currently inherit broader defaults. Update the
job definitions in `npm_release.yml` to set minimal read-only permissions while
keeping the cross-repo write path on `IOS_SPM_TOKEN`, and apply the same
restriction consistently to the other affected jobs in the workflow.
- Around line 273-278: The ios-spm checkout in the workflow is persisting the
cross-repo write token in git config, which should be avoided. Update the
checkout step using actions/checkout for ios-spm to set persist-credentials to
false, then ensure IOS_SPM_TOKEN is only provided to the step that performs the
git push during the stamping flow. Apply the same change to the other ios-spm
stamping checkout/push sequence referenced in the workflow.
- Around line 43-47: The release version selection in the npm release workflow
is currently taking the version from package.json even on tag-triggered runs, so
the publish stamp can diverge from the Git tag. Update the version resolution
logic in the workflow step that sets NPM_VERSION to detect tag builds from
GITHUB_REF, extract the tag version, and compare it against package.json before
publishing; if they differ, fail the job instead of continuing. Keep the
existing prerelease path that uses scripts/get-next-version.js for non-tag
builds, and make sure the guard lives near the NPM_VERSION assignment in the
release job.
- Around line 312-329: The publish job can run before the SwiftPM
assets/manifest workflow has finished, so gate it on the jobs that produce those
release artifacts. Update the publish job in npm_release.yml to wait for the
github-release and spm-update jobs as well as setup/build/test, using the
publish job’s dependency list so npm publishing only starts after the SPM
templates, runtime artifacts, and ios-spm tag are available.
In `@build_npm_ios.sh`:
- Around line 18-21: The template copy/stamp flow is targeting the wrong project
path because the current copy step leaves project-template-ios nested under the
framework output, while the stamp step in build_npm_ios.sh expects
__PROJECT_NAME__.xcodeproj/project.pbxproj at the framework root. Fix this by
either flattening the copy so the Xcode project lands directly under
$OUTPUT_DIR/framework or by updating the stamp-template-version.mjs invocation
to point at the actual nested project path; keep the NPM_VERSION and stamp
command aligned with the final copied location.
In `@build_npm_vision.sh`:
- Around line 18-21: The template copy step is placing the vision project under
the wrong directory, so the stamping path in build_npm_vision.sh no longer
matches the generated framework tree. Update the copy logic that creates the
framework output so the contents of project-template-vision are copied directly
into the framework directory, and then verify the stamp-template-version.mjs
target still resolves to __PROJECT_NAME__.xcodeproj/project.pbxproj within that
same framework tree.
In `@scripts/stamp-spm-release.mjs`:
- Around line 53-56: The checksum parsing in stamp-spm-release.mjs accepts
values without validation, so empty or malformed checksums can be stamped into
Package.swift and slip past strict mode. Update the checksum handling around the
parsing logic and the stamping flow (including the later stamping block) to
validate each checksum value before storing or substituting it, and reject or
fail fast on missing/invalid checksum formats using the existing checksum
map/lookup path.
---
Nitpick comments:
In @.github/workflows/npm_release.yml:
- Around line 371-413: The SPM smoke test only exercises the iOS binary
resolution, so a broken visionOS artifact could still slip through. Update the
verify-spm job to also resolve the visionOS package by adding a second probe
target/platform in the Generate a probe package step, and make sure the visionOS
product/target names match those declared in ios-spm/Package.swift so SwiftPM is
forced to fetch and checksum-validate the visionOS zips as well.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 36daa942-ade4-46ee-ac3a-afa96dc51df3
📒 Files selected for processing (12)
.github/workflows/npm_release.ymlbuild_all_ios.shbuild_all_vision.shbuild_npm_ios.shbuild_npm_vision.shbuild_spm_artifacts.shproject-template-ios/__PROJECT_NAME__.xcodeproj/project.pbxprojproject-template-ios/internal/nativescript-build.xcconfigproject-template-vision/__PROJECT_NAME__.xcodeproj/project.pbxprojproject-template-vision/internal/nativescript-build.xcconfigscripts/stamp-spm-release.mjsscripts/stamp-template-version.mjs
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
2 participants
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.
Build and release pipeline for
NativeScript.xcframeworkruntime binary to no longer be bundled inside the npm packages. Instead, they are published as GitHub Release assets and referenced via Swift Package Manager (SPM) in the Xcode project templates. The npm packages now only contain the Xcode project template and the metadata generator. The workflow is restructured to support this new distribution model, with improved artifact handling and SPM manifest stamping.Required to merge first before this: NativeScript/ios-spm#2
Summary by CodeRabbit
Summary by CodeRabbit
New Features
Bug Fixes
Chores