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

fix(mosaic-tools): roll up Gitea and Woodpecker wrapper fixes #524

Merged
jason.woltje merged 12 commits from fix/git-wrapper-rollup-20260526 into main 2026-05-26 20:56:10 +00:00
Conversation 0 Commits 12 Files Changed 26
+1173 -174
12 Commits
Author SHA1 Message Date
jarvis 67c1ad155e style(docs): satisfy task table formatting
ci/woodpecker/pr/ci Pipeline was successful
Details
ci/woodpecker/push/ci Pipeline was successful
Details
2026-05-26 15:08:46 -05:00
jarvis 9547dc8b97 fix(git-tools): validate Gitea merge API payload 2026-05-26 15:05:32 -05:00
jarvis 43b3759ce2 test(git-tools): cover rollup curl mock behavior 2026-05-26 15:02:04 -05:00
jarvis 4a7bebb1cc fix(mosaic-tools): pass explicit Gitea repo args 2026-05-26 15:00:22 -05:00
jarvis 6422c65961 fix(git): avoid duplicate gh repo flag in pr-diff 2026-05-26 14:59:16 -05:00
jarvis a70159d350 fix(git): pass explicit repo to Gitea wrappers 2026-05-26 14:59:16 -05:00
jarvis ae076e194a fix(ci): avoid postgres service collision in k8s backend 2026-05-26 14:59:16 -05:00
jarvis 7864e0b3b3 fix: handle legacy woodpecker mosaic credentials 2026-05-26 14:59:16 -05:00
Hermes Agentandjarvis 5caf85d072 fix(mosaic): reject unsafe pr merge numbers (#520) 2026-05-26 14:59:16 -05:00
Hermes Agentandjarvis 1471089c42 fix(mosaic): harden Gitea pr merge fallback (#520) 2026-05-26 14:58:39 -05:00
Hermes Agentandjarvis b7209e1e92 fix(git-tools): harden gitea pr metadata wrappers 2026-05-26 14:57:27 -05:00
Mos (Hermes)jarvisClaude Opus 4.7
 		e2d49aface fix(tools/git/pr-ci-wait): stdin collision in python3 - <<PY made wrapper always return "unknown" 
When the wrapper invoked `python3 - <<'PY' ... PY` inside a function that
was being fed JSON via a pipe (`printf '%s' "$STATUS_JSON" |
extract_state_from_status_json`), the heredoc bound stdin to the Python
program text. The `-` argument tells Python to read its program from
stdin, so the program consumed stdin before json.load(sys.stdin) ran —
which then saw EOF and bailed to the "unknown" branch every time.

Result: pr-ci-wait.sh hung the full timeout (default 30 min) even when
the upstream Gitea status was already 'success', because every poll
returned 'unknown' and the loop kept retrying.

Fix: capture the piped JSON into a local variable with `payload=$(cat)`
BEFORE invoking python, then pass it via env (PR_CI_STATUS_JSON). The
heredoc still drives the Python program, but the payload is now read
from the environment instead of a stdin that's already been consumed.

Same fix applied to print_status_summary() which has the identical
pattern.

Verified locally:
  $ echo '{"state":"success"}' | extract_state_from_status_json → success
  $ echo '' | extract_state_from_status_json → unknown
  $ echo '{"state":null,"statuses":[{"state":"success"}]}' | … → success
  $ echo '{"state":"pending"}' | extract_state_from_status_json → pending
  $ echo '{"state":"failure"}' | extract_state_from_status_json → failure

Reported in screenshot from operator session 2026-05-13 — wrapper was
stuck waiting on a PR whose underlying Gitea status was already
success. Operator workaround was to bypass the wrapper and use the raw
Gitea API.

Co-Authored-By: Claude Opus 4.7 <[email protected]>
 2026-05-26 14:57:27 -05:00