Add GitHub Action and Azure DevOps templates for building packages - #27
Conversation
action.yml lets any repo build a swiftpkg project on a macOS runner with `uses: codecarton/swiftpkg@v1` instead of hand-rolling install + invoke. It installs the swiftpkg release (Universal .pkg via `gh release download` + installer), optionally lints, builds with --output-format json (+ optional --verify/--provenance/--pkg-version/--output-dir), and exposes pkg-path, version, and sha256 as step outputs. Adapted from munki-pkg's action to swiftpkg's CLI: no --build/--no-import (swiftpkg builds by default), and the binary is installed from the release package rather than downloaded bare. README documents inputs/outputs. Requires a swiftpkg release carrying the CI flags (PRs for --output-format, --output-dir, --pkg-version, --lint, --verify).
azure-pipelines/swiftpkg-build.yml is the ADO equivalent of action.yml: a steps template another pipeline can include to install swiftpkg, optionally lint, build with --output-format json (+ optional --verify/--provenance/ --pkg-version/--output-dir), and expose pkgPath/version/sha256 as output variables on the 'build' step. Runs on a macOS agent. Adapted from munki-pkg's template to swiftpkg's CLI: installs the release Universal .pkg (asset URL resolved from the GitHub release API since the filename embeds the version) instead of a bare binary, and drops --build/--no-import.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughAdds GitHub Actions and Azure DevOps integrations that securely install swiftpkg, optionally lint projects, build Apple installer packages, and expose package path, version, and SHA-256 outputs. README documentation covers inputs, outputs, verification, and workflow usage. ChangesCI build integrations
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant CIrunner
participant GitHubReleases
participant Installer
participant Swiftpkg
participant Jq
CIrunner->>GitHubReleases: Resolve and download swiftpkg package and SHA256SUMS
CIrunner->>Installer: Verify and install swiftpkg
CIrunner->>Swiftpkg: Optionally lint and build project
Swiftpkg-->>CIrunner: Return JSON build result
CIrunner->>Jq: Extract package path, version, and SHA-256
Jq-->>CIrunner: Publish CI outputs
Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
@coderabbitai full review |
✅ Action performedFull review finished. Your included review limit is currently reached under our Fair Usage Limits Policy. This review may still proceed through usage-based billing if eligible. Your next included review will be available in 56 minutes. |
|
@coderabbitai full review |
✅ Action performedFull review finished. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 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 `@action.yml`:
- Around line 63-70: Update the SwiftPkg download/install block to create and
use a unique per-invocation directory under RUNNER_TEMP instead of the shared
runner_tmp path. After downloading, resolve the matching package into a
variable, validate that exactly one asset was found, and pass that exact path to
installer; reject zero or multiple matches.
- Around line 17-20: Update the swiftpkg-version input default so the action
does not implicitly install the moving latest release; require an explicit
version or use a specific known release. In the installation flow, verify the
exact downloaded release asset with a trusted checksum or signature before
passing it to sudo installer, rather than relying on --verify.
In `@azure-pipelines/swiftpkg-build.yml`:
- Around line 38-40: Update the swiftpkgVersion parameter in the pipeline
configuration to use a fixed immutable release instead of latest, and add
verification of the downloaded GitHub asset’s digest or signature before the
sudo installation step proceeds. Ensure installation is blocked when
verification fails.
- Line 69: Update the asset URL assignment to select only the first matching
asset within the jq expression, removing the external head -n1 pipeline stage.
Preserve the existing swiftpkg universal package filter and browser_download_url
output while ensuring pipefail cannot treat jq’s SIGPIPE as a failure.
- Around line 110-112: Update the output-variable assignments for pkgPath,
version, and sha256 to extract required non-null values with jq -er, ensure jq
failures propagate instead of being masked by echo, and escape each value
according to Azure logging-command requirements before publishing it with
task.setvariable.
In `@README.md`:
- Around line 246-250: Update the swiftpkg CI flags list in the README
documentation to include --provenance alongside the existing required flags,
matching the provenance input passed by action.yml.
🪄 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 Plus
Run ID: 140d4057-3470-4c3b-9340-70805c99fea5
📒 Files selected for processing (3)
README.mdaction.ymlazure-pipelines/swiftpkg-build.yml
…outputs Both the GitHub action and the Azure template now verify the downloaded swiftpkg installer's Developer ID signature and notarization (pkgutil --check-signature + spctl) before running it as root, and note that pinning the version is preferred over 'latest'. The action downloads into a fresh directory and requires exactly one matching asset. The Azure template selects the asset inside jq instead of piping to head (which could SIGPIPE under pipefail), extracts outputs with jq -er so a null fails the step, and strips CR/LF from output values so they can't inject a second logging command. Documented --provenance in the README.
|
All six addressed in the latest commit:
|
Both templates downloaded 'swiftpkg-*-universal.pkg'. No release has ever
published that asset. A release ships swiftpkg-<version>-cli.pkg,
swiftpkg-<version>-combined.pkg, SHA256SUMS, a universal .tar.gz and the
Swiftpkgr zip, so `gh release download` answered "no assets match the file
pattern" and the install step could never have succeeded. Ask for the CLI
package, which is what CI needs.
With the right asset selected, harden what happens to it. It is installed as
root, so three checks now stand between the download and `sudo installer`, each
covering what the others cannot:
- The caller's own swiftpkg-sha256, when set. GitHub release assets can be
replaced without moving the tag, so this is the only check that pins the
bytes; a build that must be reproducible should set it.
- SHA256SUMS from the release. It ships alongside the asset, so it moves with
a replaced release -- it catches a truncated or corrupted download, not a
substituted one.
- Developer ID Team ID plus spctl. spctl establishes that Apple notarized the
package; the Team ID establishes who signed it, which notarization alone
does not. Forging this requires the publisher's certificate.
Default swiftpkg-version to a pinned tag instead of 'latest', so a build does
not silently change when the next release ships. 'latest' still works for anyone
who wants it.
Verified against the real v0.3.1 release on macOS: the install step runs green
end to end (with sudo stubbed), and fails closed on a mismatched checksum and on
an unexpected Team ID.
|
Addressed, and the review turned up a bigger problem alongside it. The asset never existed. Both templates downloaded On the security finding: three checks now stand between the download and
Verified against the real v0.3.1 release on macOS with |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
azure-pipelines/swiftpkg-build.yml (1)
67-94: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick winAuthenticate the GitHub release metadata request
Unlikeaction.yml, this template has no token-backed GitHub API call. Unauthenticatedcurlrequests toapi.github.comcan hit the 60/hour REST limit on shared Azure-hosted agents, making this install step fail with a generic asset lookup error. Accept an optional token here and sendAuthorization: Bearer ...; adding--retry/--retry-delayto the metadata request would also reduce transient failures.🤖 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 `@azure-pipelines/swiftpkg-build.yml` around lines 67 - 94, The GitHub release metadata request in the swiftpkg install step lacks optional authentication and retry handling. Update the metadata curl for api to accept the available optional GitHub token, send it as an Authorization Bearer header when present, and add retry with delay options while preserving unauthenticated operation when no token is configured.
🤖 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.
Outside diff comments:
In `@azure-pipelines/swiftpkg-build.yml`:
- Around line 67-94: The GitHub release metadata request in the swiftpkg install
step lacks optional authentication and retry handling. Update the metadata curl
for api to accept the available optional GitHub token, send it as an
Authorization Bearer header when present, and add retry with delay options while
preserving unauthenticated operation when no token is configured.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 7a5174a6-07c3-4084-8229-6f3d80f2af41
📒 Files selected for processing (3)
README.mdaction.ymlazure-pipelines/swiftpkg-build.yml
🚧 Files skipped from review as they are similar to previous changes (1)
- README.md
2 participants
Two ready-to-use CI integrations for building packages with the tool:
action.yml) plus README usage.No source changes.
Part of a 9-PR series splitting a batch of features into small, themed, independently reviewable PRs. Each applies cleanly to
mainon its own; the ordering below only minimizes rebases as they land:Happy to squash, split, or reorder any of these to suit your review preferences.
Summary by CodeRabbit