[pull] trunk from cli:trunk#185
Merged
Merged
Conversation
The release workflow currently checks out github/cli.github.com using a personal access token (SITE_DEPLOY_PAT) owned by an individual maintainer to push generated docs, the index.html version stamp, and RPM/DEB package metadata. Replace that with a short-lived installation token minted at runtime from the new gh-cli-site-deployer GitHub App, owned by the github org and installed only on github/cli.github.com with Contents:write permission. The App's credentials live in the production environment as SITE_DEPLOY_APP_CLIENT_ID and SITE_DEPLOY_APP_PRIVATE_KEY, federated from the github-cli Vault. The token mint step is guarded on inputs.environment == 'production' because non-production environments don't have the App credentials and don't push to the site anyway (the Publish site step is already gated on DO_PUBLISH which requires production). github/cli.github.com is public, so the checkout in non-production falls back to GITHUB_TOKEN for anonymous read access, matching existing behavior. Also update docs/release-process-deep-dive.md to reflect the new flow. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Fix workflow inputs for actions/create-github-app-token by replacing the incorrect app-id key with client-id in multiple deploy job steps. This corrects the parameter name (four occurrences) so the Action receives the expected secret (DEPLOY_APP_ID) and can generate deployment tokens successfully. No other changes to the workflow or action version were made.
Update .github/workflows/deployment.yml to rename the deploy secret from DEPLOY_APP_ID to DEPLOY_APP_CLIENT_ID and adjust all create-github-app-token steps to use the new secret (client-id: ${{ secrets.DEPLOY_APP_CLIENT_ID }}). This clarifies that the secret is the GitHub App Client ID used to generate deploy tokens and keeps the workflow consistent across multiple deploy-token job invocations.
Set `timeout-minutes: 20` for the Linux, macOS, and Windows deployment jobs in the deployment workflow to prevent stalled runs from hanging indefinitely.
Gate signing in sign.ps1 on a new DO_PUBLISH env var, set in the deployment workflow to true only for production. This avoids attempting code signing in non-production environments, consistent with the existing DO_PUBLISH gating used elsewhere in the workflow. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Introduce a dry_run input (default true) to the deployment workflow so artifacts are built and signed but no GitHub Release is created and no site is published. Rename DO_PUBLISH to DO_SIGN_ARTIFACTS for the Windows signing path so signing remains driven solely by environment, independent of publish gating, and set it on the MSI signing step. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Rework the macOS deployment signing to use App Store Connect API key based notarization and a Developer ID certificate identifier. - Use a single consistent keychain (build.keychain) for signing and notarization; the notarization credentials previously targeted a keychain that was never created. - Gate the App Store Connect API key and notarization credential steps on the production environment so non-production builds (with empty secrets) no longer fail. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Convert the deployment workflow from reusable `workflow_call` to manual `workflow_dispatch`, removing the extra `repository` input and forwarded secret declarations. Drop per-job deploy app token generation and custom checkout token/repository overrides, relying on the default checkout context instead. Update release publishing to use `secrets.GITHUB_TOKEN` for GH CLI authentication.
Helps debug 'no identity found' failures by printing the codesigning identities available in the build keychain, so DEVELOPER_ID_CERT_IDENTIFIER can be verified against the actual imported certificate. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Reflects the reworked macOS code-signing/notarization flow (dedicated build.keychain, App Store Connect API key, notarytool keychain profile, DEVELOPER_ID_CERT_IDENTIFIER/MAC_APP_SIGNING_IDENTITY), documents the new dry_run input and its publishing gates, the ref input and per-job timeouts, the Windows DO_SIGN_ARTIFACTS flag, and the GitHub App site deploy token replacing SITE_DEPLOY_PAT. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The deployment workflow's dry_run input defaults to true so manual UI dispatches are safe by default. script/release, however, is used to initiate real releases, so it now passes -f dry_run=false and exposes an opt-in --dry-run flag. Without this, releases triggered via script/release silently became no-ops (no attestation, no GitHub Release, no site push). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The ref input was added in anticipation of calling this workflow via workflow_call from another repo. Since it remains a workflow_dispatch workflow, drop the input and let actions/checkout default to the ref that triggered the dispatch (the --ref passed to gh workflow run). This also fixes script/release --branch, which previously selected the workflow file ref but still built trunk because inputs.ref defaulted to trunk. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Interpolating ${{ secrets.* }} directly into the run: script meant a
certificate password containing a single quote (or other shell
metacharacters) would break quoting and could inject commands. Map the
cert and password into the step env and reference them as quoted shell
variables instead, and remove the temporary .p12 after import.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Mirror the Windows job: script/sign now skips codesign/notarization unless DO_SIGN_ARTIFACTS is set to a non-false value, and the macOS Build and Notarize steps set it to production-only. Previously, staging macOS builds would run codesign against a keychain that was never provisioned (the cert-install step is production-only) whenever MAC_APP_SIGNING_IDENTITY was defined at repository scope, breaking non-production builds. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Append a '(dry run)' suffix to run-name when inputs.dry_run is true so dry runs are distinguishable from real deployments in the Actions UI. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The workflow was reverted to source APPLE_DEVELOPER_INSTALLER_ID from vars.APPLE_DEVELOPER_INSTALLER_ID, but the docs snippet still showed vars.MAC_APP_SIGNING_IDENTITY. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The note claimed the step now passes vars.MAC_APP_SIGNING_IDENTITY, but the workflow still passes the (unset) vars.APPLE_DEVELOPER_INSTALLER_ID. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Prevents word-splitting/globbing if the keychain path ever contains spaces or glob characters. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Babak K. Shandiz <babakks@github.com>
Bring the release deep-dive in line with the final branch state: site steps gated on production, createrepo/reprepro gate on environment instead of GPG_SIGN, dropped github.token fallback, quoted keychain paths, and documented the script/release --dry-run default. Also restore the reprepro env: key that was dropped when GPG_SIGN was removed, which had left the workflow YAML invalid. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Harden deployment workflow
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )