feat(swift): optional codesigning and private SPM dependency auth#86
Conversation
Two opt-in capabilities for the shared Swift build, both off by default so existing consumers are unaffected: - entitlements: when set, ad-hoc codesign the built binary with the given entitlements plist right after swift build (mirrors local build-swift.sh). Threaded through swift-pkg-pr.yml and swift-release.yml into swift-build. - private-deps: when true, mint a short-lived owner-scoped token from the org App (APP_ID/APP_PRIVATE_KEY) and configure git so SwiftPM can clone private/internal org dependencies without listing repo names.
📝 WalkthroughWalkthroughThis PR enhances the Swift build system with support for ad-hoc code signing via entitlements plist and private GitHub dependency access. The core action adds conditional git authentication and optional codesigning steps, then both the PR and release workflows are updated to expose these features as configurable workflow inputs. ChangesSwift Build Entitlements and Private Dependencies
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested labels
Suggested reviewers
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 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 |
📚 Skills documentation may need an updateThis PR introduces changes that might not be reflected in the skills documentation. Reason:
|
📄 README may need an updateThis PR introduces changes that might not be reflected in Reason:
|
There was a problem hiding this comment.
Pull request overview
Adds two opt-in capabilities to the shared Swift GitHub Actions build/release workflows: (1) optional ad-hoc codesigning with provided entitlements, and (2) optional GitHub App token minting + git auth configuration so SwiftPM can fetch private/internal org dependencies.
Changes:
- Added
entitlementsinput to Swift PR/release workflows and to the sharedswift-buildcomposite action, with a codesign step afterswift build. - Added
private-depsinput to Swift PR/release workflows to optionally mint a GitHub App token and pass it intoswift-buildvia a newgithub-tokeninput. - Added git auth configuration logic to
swift-buildto support private SwiftPM dependency fetches.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| .github/workflows/swift-release.yml | Adds entitlements/private-deps inputs and (optionally) mints an app token to pass into the Swift build block. |
| .github/workflows/swift-pkg-pr.yml | Adds entitlements/private-deps inputs and (optionally) mints an app token to pass into the Swift build block. |
| .github/blocks/swift-build/action.yml | Adds entitlements + github-token inputs; configures git auth for private deps; performs optional ad-hoc codesigning before artifact copy. |
Comments suppressed due to low confidence (1)
.github/workflows/swift-pkg-pr.yml:40
private-depsusessecrets.APP_ID/secrets.APP_PRIVATE_KEY, but those secrets are not declared in this reusable workflow’son.workflow_call.secretsinterface. Callers won’t be able to pass them, so enablingprivate-depswill fail at runtime.
secrets:
SECRET_ENV_VARS:
required: false
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| uses: actions/create-github-app-token@v1 | ||
| with: | ||
| app-id: ${{ secrets.APP_ID }} | ||
| private-key: ${{ secrets.APP_PRIVATE_KEY }} | ||
| owner: ${{ github.repository_owner }} |
| - name: Configure git auth for private/internal SPM dependencies | ||
| if: inputs.github-token != '' | ||
| shell: bash | ||
| env: | ||
| GH_TOKEN: ${{ inputs.github-token }} | ||
| run: | | ||
| git config --global url."https://x-access-token:${GH_TOKEN}@github.com/".insteadOf "https://github.com/" |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
.github/workflows/swift-release.yml (1)
26-35: ⚡ Quick winExpose the App secrets in this reusable workflow's public contract.
private-depsadds a new caller-facing capability, but this workflow still doesn't declareAPP_ID/APP_PRIVATE_KEYunderon.workflow_call.secrets. That is fine only when every caller usessecrets: inherit; explicitly passed secrets must match the called workflow's declared secret IDs. Please add the two secrets here or document inheritance as a hard requirement. (docs.github.com)🧩 Minimal contract update
secrets: SECRET_ENV_VARS: required: false OPENAI_API_KEY: required: true JAMF_CLIENT_ID: required: false JAMF_CLIENT_SECRET: required: false + APP_ID: + required: false + APP_PRIVATE_KEY: + required: false🤖 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/swift-release.yml around lines 26 - 35, The reusable workflow exposes a new caller capability via the input private-deps but does not declare the APP_ID / APP_PRIVATE_KEY secrets in its public contract; add two secret entries under on.workflow_call.secrets named APP_ID and APP_PRIVATE_KEY (mark required: false if callers may inherit, or required: true if you want callers to always pass them) so callers can explicitly pass those secrets when using private-deps, or alternatively update the README to require secrets: inherit—modify the workflow's on.workflow_call.secrets section accordingly to include these two secret keys..github/workflows/swift-pkg-pr.yml (1)
27-36: ⚡ Quick winDeclare the new App secrets in the reusable-workflow contract, or require
secrets: inherit.This new
private-depspath depends onsecrets.APP_IDandsecrets.APP_PRIVATE_KEY, but they are not part ofon.workflow_call.secrets. GitHub's reusable-workflow contract requires explicitly passed secrets to be declared by the called workflow; the only exception is when callers usesecrets: inherit. Please either add both secrets here or confirm every caller uses inheritance, otherwise this feature becomes caller-dependent. (docs.github.com)🧩 Minimal contract update
secrets: SECRET_ENV_VARS: required: false + APP_ID: + required: false + APP_PRIVATE_KEY: + required: false🤖 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/swift-pkg-pr.yml around lines 27 - 36, The reusable workflow added the input "private-deps" which requires secrets.APP_ID and secrets.APP_PRIVATE_KEY but those secrets are not declared in on.workflow_call.secrets; update the workflow contract by adding secrets.APP_ID and secrets.APP_PRIVATE_KEY to on.workflow_call.secrets so callers must pass them, or alternatively document/require callers to invoke this workflow with "secrets: inherit"—modify the "on.workflow_call.secrets" block accordingly and ensure the symbols "private-deps", "APP_ID" and "APP_PRIVATE_KEY" are referenced consistently.
🤖 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/swift-pkg-pr.yml:
- Around line 68-75: The GitHub App token created by the step using
actions/create-github-app-token@v1 (step id "app-token") is currently scoped to
the whole installation; update that step in both swift-pkg-pr.yml and
swift-release.yml to include a repositories allowlist (the repositories input)
and restrict permissions (e.g., permission-contents: read) so the token has
least privilege before it is passed into the Swift build (github-token). Also
declare APP_ID and APP_PRIVATE_KEY in each workflow's workflow_call.secrets (or
require callers to use secrets: inherit) so those secrets are explicitly
accepted by the reusable workflow.
---
Nitpick comments:
In @.github/workflows/swift-pkg-pr.yml:
- Around line 27-36: The reusable workflow added the input "private-deps" which
requires secrets.APP_ID and secrets.APP_PRIVATE_KEY but those secrets are not
declared in on.workflow_call.secrets; update the workflow contract by adding
secrets.APP_ID and secrets.APP_PRIVATE_KEY to on.workflow_call.secrets so
callers must pass them, or alternatively document/require callers to invoke this
workflow with "secrets: inherit"—modify the "on.workflow_call.secrets" block
accordingly and ensure the symbols "private-deps", "APP_ID" and
"APP_PRIVATE_KEY" are referenced consistently.
In @.github/workflows/swift-release.yml:
- Around line 26-35: The reusable workflow exposes a new caller capability via
the input private-deps but does not declare the APP_ID / APP_PRIVATE_KEY secrets
in its public contract; add two secret entries under on.workflow_call.secrets
named APP_ID and APP_PRIVATE_KEY (mark required: false if callers may inherit,
or required: true if you want callers to always pass them) so callers can
explicitly pass those secrets when using private-deps, or alternatively update
the README to require secrets: inherit—modify the workflow's
on.workflow_call.secrets section accordingly to include these two secret keys.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 4f5b9321-da3b-4e39-94da-df2baaf448e7
📒 Files selected for processing (3)
.github/blocks/swift-build/action.yml.github/workflows/swift-pkg-pr.yml.github/workflows/swift-release.yml
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: copilot-pull-request-reviewer
- GitHub Check: check-skills / check-skills
- GitHub Check: check-readme / check-readme
🧰 Additional context used
🧠 Learnings (3)
📚 Learning: 2026-04-05T00:07:12.194Z
Learnt from: qwerzl
Repo: photon-hq/buildspace PR: 62
File: .github/workflows/update-docs.yaml:164-167
Timestamp: 2026-04-05T00:07:12.194Z
Learning: In this repo (photon-hq/buildspace), reusable workflow blocks referenced under photon-hq/buildspace (e.g., `photon-hq/buildspace/.github/blocks/<block>main`) are intentionally pinned to `main` because the blocks and workflows ship together and are kept in sync. During review, do not flag these references as version-pinning/supply-chain issues just because they use `main`; only require pinning to a release tag if there’s a separate reason (e.g., referencing an external repo or a non-controlled branch).
Applied to files:
.github/workflows/swift-pkg-pr.yml.github/workflows/swift-release.yml
📚 Learning: 2026-04-27T01:30:22.893Z
Learnt from: yanxue06
Repo: photon-hq/buildspace PR: 73
File: .github/workflows/check-readme.yaml:18-18
Timestamp: 2026-04-27T01:30:22.893Z
Learning: When reviewing this repo’s GitHub Actions workflows, treat Blacksmith runner labels like `blacksmith-4vcpu-ubuntu-2404` and other `blacksmith-*vcpu-ubuntu-*` values as valid/intentional third-party runner labels (Blacksmith: blacksmith.sh). Do not flag them as unknown or non-standard runner labels—these are an intentional drop-in replacement for GitHub-hosted runners.
Applied to files:
.github/workflows/swift-pkg-pr.yml.github/workflows/swift-release.yml
📚 Learning: 2026-04-27T01:30:22.893Z
Learnt from: yanxue06
Repo: photon-hq/buildspace PR: 73
File: .github/workflows/check-readme.yaml:18-18
Timestamp: 2026-04-27T01:30:22.893Z
Learning: In photon-hq/buildspace GitHub workflow YAML files, runner labels that match `blacksmith-*vcpu-ubuntu-*` (e.g., `blacksmith-4vcpu-ubuntu-2404`) are intentionally managed by the Blacksmith CI service (blacksmith.sh) and serve as drop-in replacements for GitHub-hosted ephemeral microVM runners. Do not flag these labels as unknown/non-standard, supply-chain concerns, or “unrecognized runner” issues; any linter/actionlint warnings about these specific labels are expected false positives.
Applied to files:
.github/workflows/swift-pkg-pr.yml.github/workflows/swift-release.yml
🪛 actionlint (1.7.12)
.github/workflows/swift-pkg-pr.yml
[error] 73-73: property "app_id" is not defined in object type {actions_runner_debug: string; actions_step_debug: string; github_token: string; secret_env_vars: string}
(expression)
[error] 74-74: property "app_private_key" is not defined in object type {actions_runner_debug: string; actions_step_debug: string; github_token: string; secret_env_vars: string}
(expression)
.github/workflows/swift-release.yml
[error] 133-133: property "app_id" is not defined in object type {actions_runner_debug: string; actions_step_debug: string; github_token: string; jamf_client_id: string; jamf_client_secret: string; openai_api_key: string; secret_env_vars: string}
(expression)
[error] 134-134: property "app_private_key" is not defined in object type {actions_runner_debug: string; actions_step_debug: string; github_token: string; jamf_client_id: string; jamf_client_secret: string; openai_api_key: string; secret_env_vars: string}
(expression)
🪛 zizmor (1.25.2)
.github/workflows/swift-pkg-pr.yml
[error] 71-71: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[error] 80-80: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[error] 75-75: dangerous use of GitHub App tokens (github-app): token granted access to all repositories for this owner's app installation
(github-app)
[error] 71-71: dangerous use of GitHub App tokens (github-app): app token inherits blanket installation permissions
(github-app)
.github/workflows/swift-release.yml
[error] 131-131: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[error] 138-138: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[error] 135-135: dangerous use of GitHub App tokens (github-app): token granted access to all repositories for this owner's app installation
(github-app)
[error] 131-131: dangerous use of GitHub App tokens (github-app): app token inherits blanket installation permissions
(github-app)
| - name: Mint app token for private SPM deps | ||
| id: app-token | ||
| if: inputs.private-deps | ||
| uses: actions/create-github-app-token@v1 | ||
| with: | ||
| app-id: ${{ secrets.APP_ID }} | ||
| private-key: ${{ secrets.APP_PRIVATE_KEY }} | ||
| owner: ${{ github.repository_owner }} |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# List relevant workflow files
ls -la .github/workflows || true
# Show the relevant sections of the PR workflow
echo "---- swift-pkg-pr.yml: lines 1-140 ----"
nl -ba .github/workflows/swift-pkg-pr.yml | sed -n '1,140p'
# If present, show release workflow too
if [ -f .github/workflows/swift-release.yml ]; then
echo "---- swift-release.yml: lines 1-200 ----"
nl -ba .github/workflows/swift-release.yml | sed -n '1,200p'
else
echo "---- swift-release.yml not found ----"
fi
# Grep for the app token output usage and github-token passing
echo "---- usages of app-token and create-github-app-token ----"
rg -n "create-github-app-token|id:\s*app-token|steps\.app-token\.outputs\.token|private-deps" .github/workflows/swift-pkg-pr.yml .github/workflows/swift-release.yml || trueRepository: photon-hq/buildspace
Length of output: 1531
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE_PR=".github/workflows/swift-pkg-pr.yml"
FILE_REL=".github/workflows/swift-release.yml"
echo "---- Token step vicinity (swift-pkg-pr.yml) ----"
awk 'NR>=45 && NR<=110 {printf "%d\t%s\n", NR, $0}' "$FILE_PR"
echo "---- Inputs/secrets contract (swift-pkg-pr.yml) ----"
awk 'NR>=1 && NR<=120 {printf "%d\t%s\n", NR, $0}' "$FILE_PR" | sed -n '1,120p'
echo "---- Find create-github-app-token usage (PR) ----"
rg -n "create-github-app-token|app-id:|private-key:|permission-|repositories:|steps\.app-token\.outputs\.token|github-token" "$FILE_PR" || true
if [ -f "$FILE_REL" ]; then
echo "---- Token step vicinity (swift-release.yml) ----"
awk 'NR>=1 && NR<=200 {printf "%d\t%s\n", NR, $0}' "$FILE_REL" | sed -n '1,200p'
echo "---- Find create-github-app-token usage (Release) ----"
rg -n "create-github-app-token|app-id:|private-key:|permission-|repositories:|steps\.app-token\.outputs\.token|github-token" "$FILE_REL" || true
else
echo "swift-release.yml not found"
fiRepository: photon-hq/buildspace
Length of output: 16600
🌐 Web query:
actions/create-github-app-token owner repositories permission-contents behavior token scope all repositories in installation
💡 Result:
The actions/create-github-app-token action allows for flexible scoping of GitHub App installation tokens within workflows [1][2]. The behavior of the token depends on the combination of the owner and repositories inputs [1][3]: - All repositories in installation: If the owner input is provided and the repositories input is empty, the generated token is scoped to all repositories available in that GitHub App installation [1][2]. - Specific repositories: If the repositories input is provided (as a comma or newline-separated list), the token is restricted to those specific repositories [2][4]. - Default (single repository): If both owner and repositories inputs are omitted, the token is scoped only to the current repository where the workflow is running [1][3]. Regarding permissions, the token inherits all permissions defined in the GitHub App's installation [1][3]. However, the action provides explicit input parameters (e.g., permission-contents, permission-issues, permission-pull-requests) that allow you to limit the token's permissions further [5][6]. It is a recommended security practice to explicitly list only the permissions required for your specific use case to follow the principle of least privilege [3][7]. Note that installation permissions must be approved by an account administrator if the app adds new permissions after the initial installation [1]. By default, the action automatically revokes the generated token after the job completes unless the skip-token-revoke input is set to true [1][4].
Citations:
- 1: https://github.com/actions/create-github-app-token/blob/34c66235f6ccc38eb01b7aed860890bdf40db33c/README.md
- 2: https://github.com/actions/create-github-app-token
- 3: https://github.com/marketplace/actions/create-github-app-token
- 4: https://buildkite.com/resources/plugins/altana-ai/create-github-app-token-buildkite-plugin/
- 5: https://github.com/actions/create-github-app-token/blob/93c1f04d6f14ea5b416e7a8dfd80446101c6adef/action.yml
- 6: https://github.com/actions/create-github-app-token/blob/29824e69f54612133e76f7eaac726eef6c875baf/action.yml
- 7: https://docs.github.com/actions/reference/authentication-in-a-workflow
🌐 Web query:
GitHub reusable workflows workflow_call secrets: inherit secrets not declared in on.workflow_call.secrets still accessible
💡 Result:
Yes, when you use secrets: inherit in a calling workflow, all secrets available to the calling workflow are passed to the reusable workflow, making them accessible even if they are not explicitly declared in the on.workflow_call.secrets section of the reusable workflow [1][2]. When secrets: inherit is used, the reusable workflow gains access to the caller's secrets at runtime [3]. This means that within your reusable workflow steps, you can directly reference secrets using the ${{ secrets.SECRET_NAME }} syntax, regardless of whether that specific secret was explicitly defined in the reusable workflow's on.workflow_call.secrets block [1][2]. Key considerations regarding this behavior include: 1. Runtime Availability: While the secrets are available at runtime for use in steps, they are not automatically available in other contexts where static validation occurs, such as in the with: block of a job call [3]. 2. Scope: Secrets are only passed to directly called workflows; they do not automatically propagate further down a chain of nested reusable workflows unless they are explicitly passed at each stage [1][2]. 3. Security/Visibility: Because secrets are passed implicitly, you do not need to update the reusable workflow's on.workflow_call configuration whenever a new secret is added to the calling repository [4]. However, this also means the reusable workflow can theoretically access any secret the caller possesses, which may be a consideration depending on your security model [4]. For these reasons, inherit is often used to simplify maintenance for reusable workflows that need to access dynamic or growing sets of secrets without requiring frequent updates to the workflow definition [4].
Citations:
- 1: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows
- 2: https://github.com/github/docs/blob/main/content/actions/how-tos/reuse-automations/reuse-workflows.md
- 3: https://dev.to/cseeman/why-your-github-actions-secrets-dont-work-in-reusable-workflow-inputs-462g
- 4: Support secret inheritence
secrets: inheritfor actions actions/toolkit#1168
Restrict the GitHub App token scope before passing it to the Swift build (in both PR + release workflows)
In both .github/workflows/swift-pkg-pr.yml and .github/workflows/swift-release.yml, actions/create-github-app-token@v1 is called with owner but no repositories allowlist, so the token is scoped to all repositories in the GitHub App installation and inherits the installation’s permissions—then that broad token is passed as github-token into the Swift build. Tighten this with an allowlist and least-privilege repo/content permissions (e.g., permission-contents: read). (github.com/actions/create-github-app-token)
- Also add
APP_ID/APP_PRIVATE_KEYto each workflow’sworkflow_call.secrets(or explicitly require callers to usesecrets: inherit), since the workflows reference those secrets even though they’re not declared inon.workflow_call.secrets.
🔐 One way to scope the token down
private-deps:
type: boolean
required: false
default: false
description: "Mint an app token (APP_ID/APP_PRIVATE_KEY) so SwiftPM can clone private/internal org dependencies."
+ private-deps-repositories:
+ type: string
+ required: false
+ default: ""
+ description: "Comma/newline-separated repository allowlist for the GitHub App token."
- name: Mint app token for private SPM deps
id: app-token
if: inputs.private-deps
uses: actions/create-github-app-token@v1
with:
app-id: ${{ secrets.APP_ID }}
private-key: ${{ secrets.APP_PRIVATE_KEY }}
owner: ${{ github.repository_owner }}
+ repositories: ${{ inputs.private-deps-repositories }}
+ permission-contents: read🧰 Tools
🪛 actionlint (1.7.12)
[error] 73-73: property "app_id" is not defined in object type {actions_runner_debug: string; actions_step_debug: string; github_token: string; secret_env_vars: string}
(expression)
[error] 74-74: property "app_private_key" is not defined in object type {actions_runner_debug: string; actions_step_debug: string; github_token: string; secret_env_vars: string}
(expression)
🪛 zizmor (1.25.2)
[error] 71-71: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[error] 75-75: dangerous use of GitHub App tokens (github-app): token granted access to all repositories for this owner's app installation
(github-app)
[error] 71-71: dangerous use of GitHub App tokens (github-app): app token inherits blanket installation permissions
(github-app)
🤖 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/swift-pkg-pr.yml around lines 68 - 75, The GitHub App
token created by the step using actions/create-github-app-token@v1 (step id
"app-token") is currently scoped to the whole installation; update that step in
both swift-pkg-pr.yml and swift-release.yml to include a repositories allowlist
(the repositories input) and restrict permissions (e.g., permission-contents:
read) so the token has least privilege before it is passed into the Swift build
(github-token). Also declare APP_ID and APP_PRIVATE_KEY in each workflow's
workflow_call.secrets (or require callers to use secrets: inherit) so those
secrets are explicitly accepted by the reusable workflow.
What
Two opt-in capabilities for the shared Swift build. Both are off by default, so existing consumers are unaffected.
1.
entitlements— ad-hoc codesigningswift-buildgains anentitlementsinput. When set, the built binary is ad-hoc codesigned with that entitlements plist right afterswift build(before it is copied toartifacts/), mirroring the localbuild-swift.sh. The signature is embedded in the Mach-O, so it survives the copy into the.pkgandpkgbuild. Needed for daemons requiring private entitlements (e.g. to connect to imagent).2.
private-deps— private/internal SPM dependency authswift-pkg-pr.yml/swift-release.ymlgain a booleanprivate-depsinput. When true, a short-lived token is minted from the existing org App (APP_ID/APP_PRIVATE_KEY), scoped to the owner (no repo list needed), and git is configured so SwiftPM can clone private/internal org dependencies.swift-buildaccepts the token via a newgithub-tokeninput.Files
.github/blocks/swift-build/action.yml—entitlements+github-tokeninputs; codesign step; git auth step..github/workflows/swift-pkg-pr.yml—entitlements+private-depsinputs; token mint; pass-through..github/workflows/swift-release.yml— same.Usage (caller)
Backward compatibility
Defaults (
entitlements: "",private-deps: false) keep current behavior — no codesigning, no token mint.Need help on this PR? Tag
@codesmithwith what you need. Autofix is disabled.Summary by CodeRabbit
Release Notes