SDK generation on release tag fails: can't open PR with base=tag
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
Direzione di ricerca
Start by reading speakeasy-workflow-executor-v15.yml around lines 185–187 and compare its behavior with the release-tag workflow and PRs #788 and #784. Check how the Speakeasy action receives the source ref and chooses the PR base; the issue describes several possible approaches but leaves the design open. Done means SDK generation uses the exact tag tree and opens a PR against a configurable branch, including for backport releases.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
The "SDK generate on release tag" workflow fails on every real release because Speakeasy tries to open a PR with base=<tag>, which GitHub rejects — tags are not valid PR bases. The current workaround in PR #788 (env.GITHUB_REF = refs/heads/main) is silently ignored by the GitHub Actions runner, because GITHUB_* default env vars cannot be overridden via env:.
Evidence
Error from generate-go / Generate Target:
Error: failed to create PR: POST https://api.github.com/repos/hookdeck/outpost/pulls:
422 Validation Failed [{Resource:PullRequest Field:base Code:invalid Message:}]
Proof the env override didn't apply — Speakeasy's generated branch name:
Creating branch speakeasy-sdk-regen-refs-tags-v0.16.0-1775848605
If GITHUB_REF had been overridden to refs/heads/main, the branch would be speakeasy-sdk-regen-refs-heads-main-…. It isn't.
Root cause
speakeasy-workflow-executor-v15.yml:185-187 sets:
env:
GITHUB_REF: ${{ inputs.pr_base_is_main == true && 'refs/heads/main' || github.ref }}
GITHUB_REF_NAME: ${{ inputs.pr_base_is_main == true && 'main' || github.ref_name }}
Per GitHub docs: "If you try to override the value of a default environment variable named CI or GITHUB_*, the value will be ignored." The runner re-sets GITHUB_REF for every step, so Speakeasy's Docker action still receives refs/tags/<tag> from the container env, passes that as the PR base, and GitHub rejects.
PR #788 merged 2026-03-25 but was never end-to-end tested against a real release tag push.
Why we can't "just dispatch from main"
The earlier approach (#784) dispatched the workflow with ref: main, which naturally gives Speakeasy a valid PR base. #788 reverted that because it broke tag fidelity — SDK was generated from main's tree, not the tag's.
More importantly, running from main precludes releasing non-latest versions:
- Patch / hotfix releases off an older minor line (e.g.
v0.15.3cut fromrelease/v0.15.x) need the SDK generated from that line, not frommain. - If
mainhas moved past the release being cut, SDK content would reflect unreleased changes. - A backport release would need to target a release branch, not
main, as the PR base.
So the fix needs to:
- Generate the SDK from the exact tag tree (whatever branch it was cut from).
- Allow the PR base to be a parameterizable branch (default
main, but e.g.release/v0.15.xfor backports).
Options to explore
- Script Speakeasy via CLI instead of the packaged action. Checkout tag →
speakeasy run→ checkout target branch → copy SDK dir → commit →gh pr create --base <target>. Full control over ref and PR base; loses some action niceties (changelog upload, code samples push, PR templating) — some can be reconstructed via CLI equivalents. - Invoke Speakeasy's Docker image directly via
docker run -e GITHUB_REF=…. Shell-exported env does reach child docker processes, bypassing GitHub'sGITHUB_*protection. Medium complexity; brittle across Speakeasy action upgrades since we'd be replicating the action's docker invocation. - Fork / upstream a
base_branchinput into Speakeasy'ssdk-generation-action. Clean long-term fix; highest upfront cost (fork maintenance or upstream lead time). - Create a transient release branch at the tag SHA (e.g.
release/<tag>), dispatch with that ref, and have Speakeasy PR into it — then a follow-up step opens a PR from the release branch into the configured target branch. Avoids modifying Speakeasy but adds branch/PR churn.
Target branch should be a workflow input (e.g. main or release/v0.15.x) so the flow supports backport releases.
References
- PR #788 — introduced the broken workaround (vendored executor +
pr_base_is_mainenv override) - PR #784 — previous approach (dispatched from
main); reverted by #788 because it didn't generate from the tag tree - GitHub Actions default env vars docs
- Lingua principale
- Go
- Stelle
- 1.1k
- Fork
- 70
- Merge medio
- 1g 18h
- PR unite (30g)
- 56
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di hookdeck/outpost
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
hookdeck/outpost#1117 · 1 commento · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di hookdeck/outpost
Issue simili
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
chaitin/agent-compose#770 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
kind/bug
Difficoltà 1/5 1-3 ore Idoneità per principianti 85/100
kubernetes-sigs/vsphere-csi-driver#4351 ·
I maintainer di solito rispondono entro 1 giorno
-
component/gpu-kubelet-plugin component/helm needs-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
kubernetes-sigs/dra-driver-nvidia-gpu#1559 ·
I maintainer di solito rispondono entro 1 giorno
-
workflow: redundant goroutine in scheduleRetryForse già presa @moodbased l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
I maintainer di solito rispondono entro 2 giorni