ci: move release flow into a GitHub Actions workflow

[dunglas]

Summary

• release.sh is reduced to a thin dispatcher: validates the semver, checks the operator is on a clean local main in sync with origin/main, then gh workflow run release.yaml -f version=$1. Tag-existence pre-check lives in the workflow itself, not the dispatcher.
• New .github/workflows/release.yaml does the work end-to-end: refresh PGO profile, bump the Caddy module's frankenphp dependency + go mod tidy, commit + tag via the GitHub REST API (Verified, github-actions[bot]), draft the release with correct previous-tag detection (handles back-ports and first releases), trigger the static / docker / windows builds explicitly (GITHUB_TOKEN-driven API writes don't fire tag/push workflows), and bump the Homebrew formula.
• The release commit message is tagged [skip ci] as a defensive belt-and-suspenders so any future switch to PAT-driven pushes doesn't double-trigger downstream builds.
• .github/workflows/pgo-profile.yaml is removed; its job is folded into the release workflow so every release commit carries a fresh profile.
• .gitignore ignores profiles/regular.pgo and profiles/worker.pgo intermediates.

Pre-reqs before first dispatch

• Create a release GitHub Environment.
• Provision HOMEBREW_TOKEN: PAT with write access to dunglas/homebrew-frankenphp. GITHUB_TOKEN covers everything else (commit/tag via REST API, draft release, downstream dispatches).

[Copilot]

Pull request overview

Moves the FrankenPHP release process from a developer-run shell script into a GitHub Actions workflow. release.sh becomes a thin dispatcher (semver validation + gh workflow run), the new release.yaml performs PGO refresh, Caddy module bump, commit/tag/push, draft GitHub release, and Homebrew formula bump on a release environment, and the standalone pgo-profile.yaml workflow is removed in favor of generating a fresh PGO profile per release.

Changes:

• Replace local-machine release script with a gh workflow run dispatcher and tag-existence pre-check.
• Add .github/workflows/release.yaml doing end-to-end release work as github-actions[bot].
• Delete .github/workflows/pgo-profile.yaml and gitignore the intermediate profiles/{regular,worker}.pgo files.

Reviewed changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 2 comments.

File	Description
release.sh	Reduced to semver validation, tag pre-check, and gh workflow run release.yaml.
.github/workflows/release.yaml	New end-to-end release workflow (PGO refresh, bump, commit, tag, push, draft release, Homebrew PR).
.github/workflows/pgo-profile.yaml	Removed; PGO refresh is now part of the release workflow.
.gitignore	Ignores profiles/regular.pgo and profiles/worker.pgo intermediates.

Comments suppressed due to low confidence (6)

.github/workflows/release.yaml:74

• workflow_dispatch can be triggered from any branch (the workflow file itself just needs to exist on the default branch, but the run executes against the dispatched ref). Because there is no guard verifying that the checked-out HEAD is main (or that it equals origin/main), dispatching this workflow from a feature branch will cause git push --follow-tags origin HEAD:main to push that branch's tip onto main and tag it as v<version>. The previous shell script explicitly verified git branch --show-current == main and that local main matched origin/main; that pre-flight protection has been lost in the move to CI. Consider adding an early step that fails if ${{ github.ref }} is not refs/heads/main, and/or fast-forwarding to origin/main before tagging.

      - name: Commit, tag, push
        env:
          VERSION: ${{ inputs.version }}
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
          git add caddy/frankenphp/default.pgo caddy/go.mod caddy/go.sum
          git commit -m "chore: prepare release ${VERSION}"
          git tag -a -m "Version ${VERSION}" "v${VERSION}"
          git tag -a -m "Version ${VERSION}" "caddy/v${VERSION}"
          git push --follow-tags origin HEAD:main

.github/workflows/release.yaml:73

• The previous release flow used git commit -S and git tag -s to produce GPG-signed release commits and signed annotated tags. The new workflow replaces these with plain git commit and git tag -a, so release tags will no longer be cryptographically signed and gh release create --verify-tag will only verify the tag exists, not that it is signed. If signed tags are an expected provenance signal for downstream consumers (Homebrew, Docker tags, distros), this is a regression. If the intent is to drop signing in favor of GitHub's commit attestation / actions identity, that decision is worth calling out explicitly in the workflow comments.

          git commit -m "chore: prepare release ${VERSION}"
          git tag -a -m "Version ${VERSION}" "v${VERSION}"
          git tag -a -m "Version ${VERSION}" "caddy/v${VERSION}"

.github/workflows/release.yaml:90

• The semver regex on line 23 (unchanged) accepts pre-release identifiers such as 1.5.0-rc1 or 2.0.0-beta.1, but the workflow unconditionally invokes gh release create ... --latest and brew bump-formula-pr ... --version "${VERSION}". Dispatching a pre-release version would therefore mark the pre-release as the "latest" GitHub release and open a Homebrew PR pointing the stable formula at it. Consider detecting a - in the version and either skipping --latest / the Homebrew bump for pre-releases, or rejecting pre-release inputs in release.sh.

          gh release create \
            --draft --generate-notes --latest \
            --notes-start-tag "${previous_tag}" \
            --verify-tag "v${VERSION}"
      - uses: Homebrew/actions/setup-homebrew@master
      - name: Bump Homebrew formula
        env:
          HOMEBREW_GITHUB_API_TOKEN: ${{ secrets.HOMEBREW_TOKEN }}
          VERSION: ${{ inputs.version }}
        run: brew bump-formula-pr dunglas/frankenphp/frankenphp --version "${VERSION}" --no-browse

.github/workflows/release.yaml:84

• previous_tag is derived by sorting all v* tags by version and taking the second entry. This runs after the new v${VERSION} tag has been created locally (line 72), so it relies on the new tag being position 1. That works when ${VERSION} is the highest semver, but for a back-port / patch on an older minor (e.g. cutting 1.4.3 after 1.5.0 already exists), --sort=-version:refname will place v1.5.0 first and the just-created v1.4.3 second, making previous_tag equal to v1.5.0 and gh release create either fail (--notes-start-tag newer than --verify-tag) or generate empty/wrong notes. Consider deriving the previous tag from git describe --tags --abbrev=0 "v${VERSION}^" or otherwise restricting to ancestors of the new tag.

          previous_tag=$(git tag --list --sort=-version:refname 'v*' | awk 'NR==2 {print;exit}')
          gh release create \
            --draft --generate-notes --latest \
            --notes-start-tag "${previous_tag}" \
            --verify-tag "v${VERSION}"

.github/workflows/release.yaml:71

• git add caddy/frankenphp/default.pgo caddy/go.mod caddy/go.sum followed by git commit will fail with nothing to commit (and abort the workflow because of set -e implicit in run: blocks) if build-pgo.sh produced no diff in default.pgo and go get was a no-op (e.g. the Caddy module was already pinned to that version, which can happen when re-running after a partial failure). Consider adding --allow-empty or guarding with git diff --cached --quiet || git commit ..., mirroring the pattern used in the deleted pgo-profile.yaml (git diff --cached --quiet && exit 0).

          git add caddy/frankenphp/default.pgo caddy/go.mod caddy/go.sum
          git commit -m "chore: prepare release ${VERSION}"

release.sh:28

• gh api "repos/:owner/:repo/git/refs/tags/v$1" uses the legacy :owner/:repo placeholder syntax. The documented gh api placeholder syntax is {owner}/{repo} (and only resolves when running inside a git repo whose remote points to the target). Since release.sh is invoked locally on the maintainer's machine, this should still work today, but the workflow on line 41 (repos/${GITHUB_REPOSITORY}/...) uses the explicit env var. Consider using repos/{owner}/{repo}/... here for consistency and to be robust against the maintainer running this from a checkout whose remote name isn't origin.

if gh api "repos/:owner/:repo/git/refs/tags/v$1" --silent 2>/dev/null; then

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 4 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (4)

.github/workflows/release.yaml:152

• git describe ... "v${VERSION}^" requires the new v${VERSION} tag (and its underlying commit object) to be present locally. The preceding step creates the commit and tag entirely through the GitHub REST API, so the local working copy still points at the original main HEAD and does not contain the new commit object. git fetch --tags origin (line 143) will fetch the tag refs, but if the new commit hasn't been advertised on a fetched branch yet, some git versions / fetch configurations won't download the dangling commit pointed to by the new annotated tag, in which case v${VERSION}^ cannot be resolved and this step fails. It is safer to also fetch origin/main explicitly (e.g. git fetch origin main --tags) and/or compute previous_tag directly via gh api against the parent SHA you already know ($parent_sha) instead of relying on local git state.

          # Sync local tags so the release-draft step can compute the previous tag.
          git fetch --tags origin
      - name: Draft GitHub release
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          VERSION: ${{ inputs.version }}
          PRERELEASE: ${{ steps.classify.outputs.prerelease }}
        # Use the parent commit of the new tag to pick the previous tag so
        # back-port releases (e.g. v1.4.3 after v1.5.0) get correct notes.
        run: |
          previous_tag=$(git describe --tags --abbrev=0 --match 'v*' --exclude "v${VERSION}" "v${VERSION}^")

.github/workflows/release.yaml:76

• go install github.com/google/pprof@latest on every release pulls a non-pinned version of pprof. This is only used for a diagnostic || true summary, but it still couples release reproducibility to whatever HEAD of pprof exists at release time and silently introduces a third-party tool with no version pinning into a workflow that has contents: write. Pin to a specific version (e.g. @v0.0.0-…) or drop the step.

      - name: Show pprof summary
        run: |
          go install github.com/google/pprof@latest
          "$(go env GOPATH)/bin/pprof" -top -cum -nodecount=25 caddy/frankenphp/default.pgo || true

.github/workflows/release.yaml:162

• mislav/bump-homebrew-formula-action@v3 is referenced by a mutable major-version tag. Other third-party actions in this workflow may follow the same pattern, but for a release workflow that holds a PAT with write access to an external repo (HOMEBREW_TOKEN), pinning to a full commit SHA is the standard supply-chain hardening recommendation (and matches what zizmor/checkov will flag). Optional but recommended.

        uses: mislav/bump-homebrew-formula-action@v3

release.sh:35

• The previous release.sh enforced that the working tree was clean and in sync with origin/main before tagging. The new dispatcher drops those checks entirely, so a developer can run ./release.sh 1.5.0 from a stale or dirty local checkout and trigger a real release without warning. Since the dispatcher's only remaining responsibilities are validation, consider re-adding the simple "are you on main / is origin up to date" guards (they cost nothing locally) so the script still fails fast for the common operator mistake of running it from the wrong branch.

if gh api "repos/:owner/:repo/git/refs/tags/v$1" --silent 2>/dev/null; then
	echo "Tag v$1 already exists on origin." >&2
	exit 1
fi

gh workflow run release.yaml -f version="$1"
echo "Release workflow dispatched for v$1."
echo "Follow progress with: gh run watch \$(gh run list --workflow=release.yaml --limit=1 --json databaseId -q '.[0].databaseId')"

[Copilot]

Pull request overview

Copilot reviewed 3 out of 4 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (4)

release.sh:46

• gh run list --limit=1 will return whatever the most recent run is, which can race with other workflows writing runs at dispatch time (and the dispatched run may not even be visible yet by the time the operator copies/pastes this command). Consider filtering by --event workflow_dispatch and/or using gh workflow run --ref main ... && sleep plus gh run list --workflow=release.yaml --user @me so the printed hint reliably resolves to the run just dispatched.

echo "Follow progress with: gh run watch \$(gh run list --workflow=release.yaml --limit=1 --json databaseId -q '.[0].databaseId')"

.github/workflows/release.yaml:127

• The Commit and tag via GitHub API step PATCHes refs/heads/main directly with the default GITHUB_TOKEN. If branch protection rules on main require status checks, a PR, or signed commits from a specific identity, this update will be rejected and the release will fail mid-flight (after the PGO refresh has already run, but before tags exist). At minimum the workflow should be tested against the actual branch protection configuration; alternatively, consider gating the push behind a step that verifies the token is allowed to bypass protections, or push from a feature branch + auto-merge.

      - name: Commit and tag via GitHub API
        # API-created commits/tags are signed server-side with GitHub's key
        # and show as "Verified" under the github-actions[bot] identity.
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          REPO: ${{ github.repository }}
          VERSION: ${{ inputs.version }}
        run: |
          set -euo pipefail

          make_blob() {
            jq -nc --arg content "$(base64 -w0 <"$1")" \
              '{content: $content, encoding: "base64"}' \
              | gh api "repos/${REPO}/git/blobs" --input - -q .sha
          }

          parent_sha=$(gh api "repos/${REPO}/git/refs/heads/main" -q .object.sha)
          base_tree=$(gh api "repos/${REPO}/git/commits/${parent_sha}" -q .tree.sha)

          pgo_sha=$(make_blob caddy/frankenphp/default.pgo)
          gomod_sha=$(make_blob caddy/go.mod)
          gosum_sha=$(make_blob caddy/go.sum)

          tree_sha=$(jq -nc \
            --arg base_tree "$base_tree" \
            --arg pgo "$pgo_sha" \
            --arg gomod "$gomod_sha" \
            --arg gosum "$gosum_sha" \
            '{
              base_tree: $base_tree,
              tree: [
                {path: "caddy/frankenphp/default.pgo", mode: "100644", type: "blob", sha: $pgo},
                {path: "caddy/go.mod", mode: "100644", type: "blob", sha: $gomod},
                {path: "caddy/go.sum", mode: "100644", type: "blob", sha: $gosum}
              ]
            }' | gh api "repos/${REPO}/git/trees" --input - -q .sha)

          commit_sha=$(jq -nc \
            --arg message "chore: prepare release ${VERSION}" \
            --arg tree "$tree_sha" \
            --arg parent "$parent_sha" \
            '{message: $message, tree: $tree, parents: [$parent]}' \
            | gh api "repos/${REPO}/git/commits" --input - -q .sha)

          gh api "repos/${REPO}/git/refs/heads/main" -X PATCH -f sha="$commit_sha" --silent

.github/workflows/release.yaml:141

• Pushing the release commit through the GitHub API as github-actions[bot] using GITHUB_TOKEN will not trigger downstream workflows on the resulting push to main or on the new tag (this is GitHub's documented behavior to prevent recursion). The previous setup created the commit via local git push from a user-authenticated gh CLI, so any tag-triggered workflows (e.g. static.yaml/docker.yaml/windows.yaml that build on tag refs) would fire. Verify whether the release pipeline depends on tag-push triggers; if it does, switch to a PAT (or GitHub App token) to push the commit/tag, or invoke the downstream workflows explicitly via workflow_dispatch.

        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          REPO: ${{ github.repository }}
          VERSION: ${{ inputs.version }}
        run: |
          set -euo pipefail

          make_blob() {
            jq -nc --arg content "$(base64 -w0 <"$1")" \
              '{content: $content, encoding: "base64"}' \
              | gh api "repos/${REPO}/git/blobs" --input - -q .sha
          }

          parent_sha=$(gh api "repos/${REPO}/git/refs/heads/main" -q .object.sha)
          base_tree=$(gh api "repos/${REPO}/git/commits/${parent_sha}" -q .tree.sha)

          pgo_sha=$(make_blob caddy/frankenphp/default.pgo)
          gomod_sha=$(make_blob caddy/go.mod)
          gosum_sha=$(make_blob caddy/go.sum)

          tree_sha=$(jq -nc \
            --arg base_tree "$base_tree" \
            --arg pgo "$pgo_sha" \
            --arg gomod "$gomod_sha" \
            --arg gosum "$gosum_sha" \
            '{
              base_tree: $base_tree,
              tree: [
                {path: "caddy/frankenphp/default.pgo", mode: "100644", type: "blob", sha: $pgo},
                {path: "caddy/go.mod", mode: "100644", type: "blob", sha: $gomod},
                {path: "caddy/go.sum", mode: "100644", type: "blob", sha: $gosum}
              ]
            }' | gh api "repos/${REPO}/git/trees" --input - -q .sha)

          commit_sha=$(jq -nc \
            --arg message "chore: prepare release ${VERSION}" \
            --arg tree "$tree_sha" \
            --arg parent "$parent_sha" \
            '{message: $message, tree: $tree, parents: [$parent]}' \
            | gh api "repos/${REPO}/git/commits" --input - -q .sha)

          gh api "repos/${REPO}/git/refs/heads/main" -X PATCH -f sha="$commit_sha" --silent

          create_tag() {
            local tag_sha
            tag_sha=$(jq -nc \
              --arg tag "$1" \
              --arg message "Version ${VERSION}" \
              --arg object "$commit_sha" \
              '{tag: $tag, message: $message, object: $object, type: "commit"}' \
              | gh api "repos/${REPO}/git/tags" --input - -q .sha)
            gh api "repos/${REPO}/git/refs" -f ref="refs/tags/$1" -f sha="$tag_sha" --silent
          }

          create_tag "v${VERSION}"
          create_tag "caddy/v${VERSION}"

.github/workflows/release.yaml:161

• If the bash variable previous_tag is empty (e.g. the very first release, or git describe failing for any reason), gh release create would still be invoked with --notes-start-tag "", which is at best meaningless and at worst causes a confusing failure. Because set -e is on by default for GitHub Actions bash, a non-zero git describe should abort the step, but that aborts the entire release after the tag has already been created, leaving the repo in a half-released state. Consider validating previous_tag is non-empty before calling gh release create, or moving the release-draft step to run before the tags are created so a failure here is recoverable.

        run: |
          previous_tag=$(git describe --tags --abbrev=0 --match 'v*' --exclude "v${VERSION}" "v${VERSION}^")
          args=(--draft --generate-notes --notes-start-tag "${previous_tag}" --verify-tag "v${VERSION}")
          if [[ "${PRERELEASE}" == "true" ]]; then
            args+=(--prerelease)
          else
            args+=(--latest)
          fi
          gh release create "v${VERSION}" "${args[@]}"

[Copilot]

Pull request overview

Copilot reviewed 3 out of 4 changed files in this pull request and generated 7 comments.