mosaicstack/stack
16
0
Fork 1
Code Issues 330 Pull Requests 12 Actions Packages Projects Releases 15 Wiki Activity

fix(git-tools): pr-create API fallback resolves base from forge default branch (E4) #1376

Merged
orch-01 merged 2 commits from t51p2wp5a-pr-create-default-base into next 2026-08-24 02:49:38 +00:00
Conversation 1 Commits 2 Files Changed 5
+252 -5
2 Commits
Author SHA1 Message Date
code-be-02 99dbd8cfb6 fix(git-tools): WP5a rework — authoritative curl status, string-validated base, CI enumeration (E4)
ci/woodpecker/pr/ci Pipeline was successful
Details 
T51P2WP5AR B1-B3 + I1 on the default-base fallback:

B1: test-pr-create-fallback-default-base.sh is now enumerated on the
canonical S1 surface (packages/mosaic package.json test:framework-shell,
git-tools cluster). Enumeration guard: population 67, enumerated 53,
excluded 15 — green; the meta-test passes 14/14. PR pipeline 2623's
sanitization failure clears on the next run.

B2: gitea_default_branch fetches and parses as separate steps. The old
`curl | python` pipeline reported only python's status, so an HTTP
failure that still emitted parseable JSON masqueraded as success and
POSTed. curl's exit status is now authoritative (rc nonzero -> failed
resolution, loud -B remedy, no POST). Fixture: valid JSON + curl rc 22.

B3: default_branch is valid only as a nonblank JSON string. null (which
printed as the literal "None"), numbers, and whitespace-only strings were
all POSTed as bases. The python step now type- and blank-checks; null /
numeric / blank fixtures each produce rc 1, loud -B remedy, no POST.

I1: --help now says the default base is the forge repository's default
branch (was main/master, the removed behavior).

Suite: 29 asserts (16 prior + 4 B2 + 9 B3), green x2. Sweep 32/33;
test-issue-close-fail-closed.sh fails identically at baseline origin/next
(pre-existing, untouched).
 2026-08-23 21:19:02 -05:00
code-be-02 578716a0ed fix(git-tools): pr-create API fallback resolves base from forge default branch (E4)
ci/woodpecker/pr/ci Pipeline failed
Details 
The API-fallback payload hardcoded "base": "main", mistargeting every
fallback PR on repos whose trunk is not main. With zero fleet tea logins
(measured under T53) every pr-create takes the fallback, so stack repos
(default branch next) got main-targeted PRs.

gitea_pr_create_api now resolves the base when -B is omitted:
gitea_default_branch() queries the provider repo API
(GET /api/v1/repos/<owner>/<repo> -> default_branch) using the same
host/repo/token resolution as the POST itself. Explicit -B still wins and
skips the lookup entirely. A failed or empty resolution fails loud
(-B remedy named) instead of guessing a base; the "main" literal is gone.

Hermetic suite test-pr-create-fallback-default-base.sh (PATH-stubbed curl,
sandbox HOME, git.example.test fixture): no -B -> payload base equals the
stubbed forge default (next) with the repo GET performed; explicit -B wins
with zero repo GETs; lookup failure -> loud refusal, no POST; the literal
main never appears as a fallback. Fixture stubs in
test-gitea-login-resolution.sh and test-issue-create-interactive-auth.sh
gain repo-root answers (assertions unchanged) because the fallback now
makes a call those stubs predated.

Sweep: 32/33 git-tools suites green; test-issue-close-fail-closed.sh fails
identically at baseline origin/next (pre-existing, untouched).
 2026-08-23 20:51:03 -05:00