fix(ci): whatsnew highlights — set GH_REPO so gh runs without a checkout

Release Please Beta on v3.76.1-beta.0 hard-failed at the very first `gh release view "$TAG"` call: failed to run git: fatal: not a git repository (or any of the parent directories): .git The reusable `whatsnew-highlights.yml` (PR #703) doesn't run actions/checkout — so when `gh` tried to infer the target repo from the runner's empty workspace it errored out. The first time it ran against an actual release (#709 → 3.76.1-beta.0), the whole job died before the deterministic-fallback path could save it. Two changes, both single-line: 1. `env.GH_REPO: ${{ github.repository }}` at job scope. `gh` honours this and won't fall back to parsing `.git/config`, so no checkout is needed (the workflow only calls the GitHub API, never reads repo files). 2. `continue-on-error: true` on the "Extract Features" step. The file's comments say "never let highlights break a release", but the original wiring only soft-failed the AI + inject steps. A transient API hiccup at extract still hard-failed the whole job — defeating the design intent. Match the comment. Why not just add actions/checkout? It would work, but pulls the whole repo over the wire on every release just for `gh` to read its own config. GH_REPO is the lighter idiom. Net impact today: v3.76.1-beta.0 shipped without the `` block; the app's parseWhatsNew() already falls back to the raw Features list so the admin "What's New" banner still works. The next beta release will pick up the polished version.
2026-06-30 22:47:10 +02:00
parent 152952877f
commit 2a5f0a8601
1 changed files with 13 additions and 0 deletions
@@ -38,9 +38,22 @@ jobs:
    permissions:
      contents: write   # to edit the release body
      models: read      # GitHub Models (free tier)
+    # GH_REPO at job scope so every `gh` call targets the right repo without
+    # needing an actions/checkout step. Without this, `gh` falls back to
+    # parsing `.git/config` in the runner's empty workspace and dies with
+    # "fatal: not a git repository" — which hard-fails the whole job before
+    # any continue-on-error can save it.
+    env:
+      GH_REPO: ${{ github.repository }}
    steps:
      - name: Extract Features from the published release
        id: feat
+        # Belt-and-braces: the job-level comment says "never let highlights
+        # break a release", but the original wiring only marked the AI +
+        # inject steps as continue-on-error. A hiccup here (rate limit,
+        # transient API error) would still hard-fail the job. Match the
+        # design intent and fail soft.
+        continue-on-error: true
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          TAG: ${{ inputs.tag }}