fix(ci): prevent duplicate Update API Client PRs (HYBIM-922)

[etserend]

Summary

• Root cause: branch name included ${{ github.run_id }}, so every workflow run created a new unique branch and PR
• Fix: use a static branch name chore/splunk-ao-automation/update-api-client and force-push to it
• PR creation step now checks for an existing open PR; skips gh pr create if one already exists

Test plan

• Trigger the regenerate-api-client workflow manually from this branch and verify it runs without errors
• Trigger it a second time and verify no duplicate PR is created — the existing one is updated instead

Jira: https://splunk.atlassian.net/browse/HYBIM-922

🤖 Generated with Claude Code

[fercor-cisco]

🤖 This review was generated by the Astra agent (claude-opus-4-8). It may contain mistakes.

Verdict: request_changes — Static branch name breaks the "nothing was committed this run" guard in the PR-creation step, which can resurrect spurious PRs or fail the job; force-push also silently discards manual fixes on the open branch.

[fercor-cisco]

🟠 major (bug): This step's guard no longer means what it used to. Previously the branch name was unique per run (...-{date}-{run_id}), so git ls-remote refs/heads/$BRANCH_NAME succeeding was a reliable proxy for "this run actually committed and pushed". With a static branch name, ls-remote now succeeds whenever the branch exists from ANY prior run, even when the current run made no spec changes (step 1 hit the exit 0 at line 58-60 and never pushed).

Concrete failure: a previous run created the branch + PR, the PR was later closed or merged but the remote branch was not deleted. Today's scheduled run finds no spec changes, so step 1 doesn't push. Step 2 still runs (no if: gate, no dependency on step 1), ls-remote passes because the stale branch exists, EXISTING_PR is empty (old PR is closed), so gh pr create fires — either resurrecting a PR from stale content or failing with "No commits between main and ..." when the branch equals main. Either way this reintroduces the duplicate/spurious-PR behavior the ticket set out to eliminate, or turns the job red.

Fix: have step 1 emit an explicit output (e.g. echo "changed=true" >> "$GITHUB_OUTPUT" after a successful push, via a step id) and gate this step on it (if: steps.<id>.outputs.changed == 'true'), rather than inferring "did we commit" from branch existence.

🤖 Generated by the Astra agent

[fercor-cisco]

Pushing back on the Claude review:

force-push also silently discards manual fixes on the open branch.

This is fine, these PRs are supposed to be automated, not manually edited.

[fercor-cisco]

Verdict: approve — the blocker from the earlier review is resolved and the logic is correct.

The core fix is sound:

• Step 1 has id: regenerate and emits changed=true/false on both paths.
• Step 2 is gated with if: steps.regenerate.outputs.changed == 'true', and the fragile git ls-remote guard is gone.

A stale branch lingering from a closed/merged prior run can no longer trigger a spurious gh pr create or a red "No commits between main and ..." job, because Step 2 simply doesn't run when nothing was pushed. That closes the exact failure previously flagged.

Remaining branches check out:

• git checkout -b runs on a fresh runner from main, so --force overwriting the persistent remote branch is intended.
• When Step 2 runs, the branch is guaranteed freshly pushed, so the EXISTING_PR check is now just update-vs-create routing — correct and worth keeping.

Minor points (non-blocking)

1. Dead step — "Get current date" (id: date). Its only consumer was the old branch name; steps.date.outputs.date no longer appears anywhere in the file, so the step is now dead. Worth deleting for tidiness.
2. Daily force-push churn. git diff --cached --quiet compares against main, not the prior run — so while a PR is open, each scheduled run force-pushes a fresh commit and re-notifies even when the spec hasn't moved since yesterday. Noise, not a bug; the "no duplicate PRs" goal still holds.

None of these block merge.

[fercor-cisco]

@etserend this seems to be dead code, do you want to remove this before merging?

Dead step — "Get current date" (id: date, near line 42). Its only consumer was the old branch name (...-${{ steps.date.outputs.date }}-...). steps.date.outputs.date no longer appears anywhere in the file, so that whole step is now dead. Worth deleting for tidiness.

[etserend]

@etserend this seems to be dead code, do you want to remove this before merging?

Dead step — "Get current date" (id: date, near line 42). Its only consumer was the old branch name (...-${{ steps.date.outputs.date }}-...). steps.date.outputs.date no longer appears anywhere in the file, so that whole step is now dead. Worth deleting for tidiness.

Will clean up in this PR.