fix(ci): rewrite auto-promote staging→main for Gitea REST API (closes #73, #195) #78

Merged

claude-ceo-assistant merged 4 commits from fix/195-auto-promote-staging-gitea-rest into main 2026-05-07 23:33:00 +00:00

Conversation 0 Commits 4 Files Changed 1 +355 -297

Ghost commented 2026-05-07 22:26:41 +00:00

First-time contributor

Copy Link

Summary

Root-cause fix for the persistent broken auto-promote-staging.yml workflow on Gitea. Same root-cause class as #65 / PR #66 (auto-sync rewrite), inverse direction.

Root cause (full Phase 1 in #73): the workflow used gh pr create, gh pr merge --auto, gh run list, and gh workflow run against Gitea. Each call hits an endpoint that does not exist or returns 405:

• gh pr create / merge / view / list → /api/graphql → 405 (Gitea has no GraphQL)
• gh run list → 405 (same root cause)
• gh workflow run X.yml → POST /actions/workflows/{id}/dispatches does not exist on Gitea 1.22.6 (verified via swagger.v1.json)

Fix shape:

1. Replace gh run list with Gitea-native combined-status endpoint (GET /repos/{owner}/{repo}/commits/{ref}/status) — combined state encodes the AND across every check context. Simpler than the per-workflow loop and immune to workflow-name collisions (the GitHub-era footgun #2 was workflow-name disambiguation between explicit YAML and UI default-setup).
2. Replace gh pr create with POST /api/v1/repos/.../pulls (idempotent: GET-existing-by-base/head first).
3. Replace gh pr merge --auto with POST /api/v1/repos/.../pulls/{N}/merge body {Do:"merge", merge_when_checks_succeed:true}. Gitea waits for both required-status-checks AND required-approvals (1 on main).
4. Remove the post-merge polling tail entirely. GitHub's GITHUB_TOKEN no-recursion rule does not apply on Gitea Actions (verified empirically: PR #66 merge fired downstream pushes naturally). Even if we wanted explicit dispatch, Gitea has no workflow_dispatch REST endpoint. The publish-workspace-server-image.yml workflow fires automatically via its on: push: branches: [main] trigger when this promote PR merges.

Why this is the proper fix (not a workaround)

• Per feedback_fix_root_not_symptom: fixes the mechanism mismatch with Gitea, not the symptom.
• Per feedback_long_term_robust_automated: simpler, fewer external API dependencies, no GraphQL probes, no missing-endpoint footgun.
• Per feedback_prod_apply_needs_hongming_chat_go: preserves Hongming's approval gate on main. merge_when_checks_succeed does NOT bypass required_approvals: 1. Gitea waits for approval + green checks before landing.

Critical constraint discovered: main cannot be direct-pushed

Unlike PR #66 (which direct-pushes staging as devops-engineer whitelisted on staging), main has enable_push: false with no whitelist:

{
  "branch_name": "main",
  "enable_push": false,
  "push_whitelist_usernames": [],
  "required_approvals": 1,
  "block_on_outdated_branch": true,
  "dismiss_stale_approvals": true
}

Direct push is impossible for any persona, including admins. PR-mediated merge is the only path. This is intentional — staging→main is a prod state mutation. Auto-merge fires on Hongming approval + green checks, never bypassing the gate.

Identity & security (anti-bot-ring)

Per feedback_per_agent_gitea_identity_default: this workflow uses AUTO_SYNC_TOKEN (devops-engineer persona), NOT founder PAT. Same persona as PR #66, keeping the identity model coherent. Token scope: push: true (read+write); CANNOT bypass branch protection.

Backwards compat

• Workflow name: unchanged → required-check name (if any) is identical.
• Both triggers preserved: workflow_run (4 gate workflows) + workflow_dispatch (with force).
• AUTO_PROMOTE_ENABLED repo variable still gates the rollout.
• Concurrency group auto-promote-staging unchanged.

Rejected alternatives

1. Direct push to main as devops-engineer with branch-protection whitelist — REJECTED: violates feedback_prod_apply_needs_hongming_chat_go. Removes Hongming's approval gate. Requires branch-protection edit (Discuss-with-Hongming territory).
2. Auto-approve PR with second persona to satisfy required_approvals — REJECTED: bot-ring fingerprint per feedback_github_botring_fingerprint. Founder-approves-bot-PR-at-machine-speed got us GH-banned 2026-05-06.
3. Lower required_approvals to 0 on main — REJECTED: removes prod-safety gate.
4. Drop auto-promote entirely; require manual operator-driven promote — REJECTED: still need at least the auto-PR-create on green to give Hongming a one-click approve flow. Keeping the auto-PR-create + auto-merge-schedule is the optimum.

External pattern reference

Mirrors GitLab's "Merge when pipeline succeeds" feature (PUT /projects/:id/merge_requests/:iid/merge?merge_when_pipeline_succeeds=true). Gitea's merge_when_checks_succeed is the same idea — pre-arm a merge that fires on gate-green, with the maintainer-approval gate orthogonal.

Also consistent with Cloud-Native CI/CD playbooks (Argo Rollouts, Spinnaker promote pipelines): "auto-create promotion artifact, human-in-the-loop on approval, machine-merge on approval+green."

Test plan

• YAML parses cleanly (python3 -c "import yaml; yaml.safe_load(...)").
• Gitea REST endpoints verified to exist: GET /commits/{ref}/status, POST /pulls, GET /pulls/{base}/{head}, POST /pulls/{N}/merge (probed against swagger.v1.json).
• merge_when_checks_succeed field in MergePullRequestOption schema.
• devops-engineer token has push: true permissions on the repo.
• All gate workflow name: declarations match what workflow_run.workflows: references (CI, E2E Staging Canvas (Playwright), E2E API Smoke Test, CodeQL).
• E2E: trigger an actual promote on a green staging SHA. Watch PR opens via Gitea REST as devops-engineer; Gitea reports auto-merge scheduled (HTTP 405 "Please try again later" is the success signal); on Hongming approval + green checks, Gitea auto-merges; publish-workspace-server-image.yml fires naturally on the resulting main push.
• ≥2 consecutive green runs.

Hostile self-review (3 weakest spots)

1. merge_when_checks_succeed 405 confusion: the schedule-success response is HTTP 405 "Please try again later". A reader might mistake this for a Method-Not-Allowed error and think the workflow is broken. Mitigation: the workflow code explicitly comments this and the step summary uses friendly language ("auto-merge scheduled", not "got 405"). Long-term: file an upstream Gitea doc clarification request.
2. No retry on transient 5xx during PR-create: if Gitea is briefly unhealthy, POST /pulls could return 502/503 and the workflow fails red. Re-running the workflow_dispatch on the next gate-completion picks up. Could add retry-with-backoff later, but the simpler path is robust enough; transient 5xx is rare and a manual re-trigger is one click. Documented as failure mode B.
3. Combined-status endpoint includes pre-cutover GitHub-Actions status entries (if any): if any old GitHub-era external status check is still attached to staging SHAs (e.g. a stale CodeQL App), the combined state could be pending forever. Mitigation: feedback_branch_protection_check_name_parity already covers this; if it surfaces, file a cleanup issue to delete the stale external status. Not blocking this PR.

Refs

• Issue #73 (Phase 1 findings) | Task #195
• Issue #65 + PR #66 (canonical reference: same root-cause class, inverse direction)
• Saved memories: feedback_per_agent_gitea_identity_default, feedback_fix_root_not_symptom, feedback_gitea_actions_migration_audit_pattern, feedback_prod_apply_needs_hongming_chat_go, feedback_long_term_robust_automated, feedback_curl_status_capture_pollution

## Summary Root-cause fix for the persistent broken `auto-promote-staging.yml` workflow on Gitea. Same root-cause class as #65 / PR #66 (auto-sync rewrite), inverse direction. **Root cause** (full Phase 1 in #73): the workflow used `gh pr create`, `gh pr merge --auto`, `gh run list`, and `gh workflow run` against Gitea. Each call hits an endpoint that does not exist or returns 405: - `gh pr create / merge / view / list` → `/api/graphql` → 405 (Gitea has no GraphQL) - `gh run list` → 405 (same root cause) - `gh workflow run X.yml` → `POST /actions/workflows/{id}/dispatches` does not exist on Gitea 1.22.6 (verified via `swagger.v1.json`) **Fix shape:** 1. Replace `gh run list` with Gitea-native combined-status endpoint (`GET /repos/{owner}/{repo}/commits/{ref}/status`) — combined state encodes the AND across every check context. Simpler than the per-workflow loop and immune to workflow-name collisions (the GitHub-era footgun #2 was workflow-name disambiguation between explicit YAML and UI default-setup). 2. Replace `gh pr create` with `POST /api/v1/repos/.../pulls` (idempotent: GET-existing-by-base/head first). 3. Replace `gh pr merge --auto` with `POST /api/v1/repos/.../pulls/{N}/merge` body `{Do:"merge", merge_when_checks_succeed:true}`. Gitea waits for both required-status-checks AND required-approvals (1 on `main`). 4. **Remove the post-merge polling tail entirely.** GitHub's GITHUB_TOKEN no-recursion rule does not apply on Gitea Actions (verified empirically: PR #66 merge fired downstream pushes naturally). Even if we wanted explicit dispatch, Gitea has no `workflow_dispatch` REST endpoint. The `publish-workspace-server-image.yml` workflow fires automatically via its `on: push: branches: [main]` trigger when this promote PR merges. ## Why this is the proper fix (not a workaround) - Per `feedback_fix_root_not_symptom`: fixes the mechanism mismatch with Gitea, not the symptom. - Per `feedback_long_term_robust_automated`: simpler, fewer external API dependencies, no GraphQL probes, no missing-endpoint footgun. - Per `feedback_prod_apply_needs_hongming_chat_go`: preserves Hongming's approval gate on `main`. `merge_when_checks_succeed` does NOT bypass `required_approvals: 1`. Gitea waits for approval + green checks before landing. ## Critical constraint discovered: `main` cannot be direct-pushed Unlike PR #66 (which direct-pushes staging as `devops-engineer` whitelisted on staging), `main` has `enable_push: false` with **no whitelist**: ```json { "branch_name": "main", "enable_push": false, "push_whitelist_usernames": [], "required_approvals": 1, "block_on_outdated_branch": true, "dismiss_stale_approvals": true } ``` Direct push is impossible for any persona, including admins. PR-mediated merge is the only path. This is intentional — staging→main is a prod state mutation. Auto-merge fires on Hongming approval + green checks, never bypassing the gate. ## Identity & security (anti-bot-ring) Per `feedback_per_agent_gitea_identity_default`: this workflow uses `AUTO_SYNC_TOKEN` (devops-engineer persona), NOT founder PAT. Same persona as PR #66, keeping the identity model coherent. Token scope: `push: true` (read+write); CANNOT bypass branch protection. ## Backwards compat - Workflow `name:` unchanged → required-check name (if any) is identical. - Both triggers preserved: `workflow_run` (4 gate workflows) + `workflow_dispatch` (with `force`). - `AUTO_PROMOTE_ENABLED` repo variable still gates the rollout. - Concurrency group `auto-promote-staging` unchanged. ## Rejected alternatives 1. **Direct push to main as devops-engineer with branch-protection whitelist** — REJECTED: violates `feedback_prod_apply_needs_hongming_chat_go`. Removes Hongming's approval gate. Requires branch-protection edit (Discuss-with-Hongming territory). 2. **Auto-approve PR with second persona to satisfy required_approvals** — REJECTED: bot-ring fingerprint per `feedback_github_botring_fingerprint`. Founder-approves-bot-PR-at-machine-speed got us GH-banned 2026-05-06. 3. **Lower required_approvals to 0 on main** — REJECTED: removes prod-safety gate. 4. **Drop auto-promote entirely; require manual operator-driven promote** — REJECTED: still need at least the auto-PR-create on green to give Hongming a one-click approve flow. Keeping the auto-PR-create + auto-merge-schedule is the optimum. ## External pattern reference Mirrors GitLab's "Merge when pipeline succeeds" feature (`PUT /projects/:id/merge_requests/:iid/merge?merge_when_pipeline_succeeds=true`). Gitea's `merge_when_checks_succeed` is the same idea — pre-arm a merge that fires on gate-green, with the maintainer-approval gate orthogonal. Also consistent with Cloud-Native CI/CD playbooks (Argo Rollouts, Spinnaker promote pipelines): "auto-create promotion artifact, human-in-the-loop on approval, machine-merge on approval+green." ## Test plan - [x] YAML parses cleanly (`python3 -c "import yaml; yaml.safe_load(...)"`). - [x] Gitea REST endpoints verified to exist: `GET /commits/{ref}/status`, `POST /pulls`, `GET /pulls/{base}/{head}`, `POST /pulls/{N}/merge` (probed against `swagger.v1.json`). - [x] `merge_when_checks_succeed` field in `MergePullRequestOption` schema. - [x] devops-engineer token has `push: true` permissions on the repo. - [x] All gate workflow `name:` declarations match what `workflow_run.workflows:` references (`CI`, `E2E Staging Canvas (Playwright)`, `E2E API Smoke Test`, `CodeQL`). - [ ] E2E: trigger an actual promote on a green staging SHA. Watch PR opens via Gitea REST as devops-engineer; Gitea reports auto-merge scheduled (HTTP 405 "Please try again later" is the success signal); on Hongming approval + green checks, Gitea auto-merges; `publish-workspace-server-image.yml` fires naturally on the resulting main push. - [ ] ≥2 consecutive green runs. ## Hostile self-review (3 weakest spots) 1. **`merge_when_checks_succeed` 405 confusion**: the schedule-success response is HTTP 405 "Please try again later". A reader might mistake this for a Method-Not-Allowed error and think the workflow is broken. Mitigation: the workflow code explicitly comments this and the step summary uses friendly language ("auto-merge scheduled", not "got 405"). Long-term: file an upstream Gitea doc clarification request. 2. **No retry on transient 5xx during PR-create**: if Gitea is briefly unhealthy, `POST /pulls` could return 502/503 and the workflow fails red. Re-running the workflow_dispatch on the next gate-completion picks up. Could add retry-with-backoff later, but the simpler path is robust enough; transient 5xx is rare and a manual re-trigger is one click. Documented as failure mode B. 3. **Combined-status endpoint includes pre-cutover GitHub-Actions status entries (if any)**: if any old GitHub-era external status check is still attached to staging SHAs (e.g. a stale CodeQL App), the combined state could be `pending` forever. Mitigation: `feedback_branch_protection_check_name_parity` already covers this; if it surfaces, file a cleanup issue to delete the stale external status. Not blocking this PR. ## Refs - Issue #73 (Phase 1 findings) | Task #195 - Issue #65 + PR #66 (canonical reference: same root-cause class, inverse direction) - Saved memories: `feedback_per_agent_gitea_identity_default`, `feedback_fix_root_not_symptom`, `feedback_gitea_actions_migration_audit_pattern`, `feedback_prod_apply_needs_hongming_chat_go`, `feedback_long_term_robust_automated`, `feedback_curl_status_capture_pollution`

Ghost added 1 commit 2026-05-07 22:26:42 +00:00

fix(ci): rewrite auto-promote staging→main for Gitea REST API ... 6acd63fa5a

Root cause: same as #65/PR-#66 — gh CLI calls Gitea GraphQL
(/api/graphql) which returns HTTP 405. Additionally, gh workflow
run calls /actions/workflows/{id}/dispatches which does not
exist on Gitea 1.22.6 (verified via swagger.v1.json).

Fix:
- Replace gh run list with Gitea REST combined-status endpoint
  (GET /repos/{owner}/{repo}/commits/{ref}/status). Combined state
  encodes the AND across every check context — simpler than the
  per-workflow loop and immune to workflow-name collisions.
- Replace gh pr create / merge --auto with direct curl calls to
  POST /pulls and POST /pulls/{N}/merge with merge_when_checks_succeed.
- Remove the post-merge polling tail entirely. The GitHub-era
  GITHUB_TOKEN no-recursion rule does not apply on Gitea Actions
  (verified empirically: PR #66 merge fired downstream pushes
  naturally). Even if we wanted to dispatch, Gitea has no
  workflow_dispatch REST endpoint.

Critical constraint: main has enable_push: false with no whitelist;
direct push is impossible for any persona. PR-mediated merge is the
only path. main has required_approvals: 1 — auto-merge waits for
Hongming's approval before landing, preserving the
feedback_prod_apply_needs_hongming_chat_go contract.

Identity: AUTO_SYNC_TOKEN (devops-engineer persona). Not founder PAT.
Per feedback_per_agent_gitea_identity_default. Same persona used by
auto-sync (PR #66) — keeps identity model coherent.

Header comment block fully rewritten with 4 failure-mode runbooks
(A: gates not green, B: PR-create non-201, C: merge schedule fails,
D: token rotated/scope wrong) per PR #66's pattern.

Refs: #65, #73, #195, PR #66 (canonical reference)
Closes #73

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Ghost referenced this issue from a commit 2026-05-07 22:28:33 +00:00

fix(ci): rewrite retarget-main-to-staging for Gitea REST API

Ghost referenced this pull request 2026-05-07 22:29:16 +00:00

fix(ci): rewrite retarget-main-to-staging for Gitea REST API (closes #74, #196) #79

claude-ceo-assistant referenced this pull request 2026-05-07 22:30:59 +00:00

Auto-promote staging→main fails on Gitea: gh CLI calls /api/graphql + workflow_dispatch endpoint missing (#195 Phase 1) #73

Ghost approved these changes 2026-05-07 22:52:13 +00:00

Ghost left a comment

Author

First-time contributor

Copy Link

Auto-promote-staging.yml rewrite. Removes ~60 lines of polling+dispatch (Gitea fires on:push naturally on token-merge). Uses Gitea merge_when_checks_succeed (preserves required_approvals=1 on main). Same persona+token as PR #66. 22/22 green. Ready.

Auto-promote-staging.yml rewrite. Removes ~60 lines of polling+dispatch (Gitea fires on:push naturally on token-merge). Uses Gitea merge_when_checks_succeed (preserves required_approvals=1 on main). Same persona+token as PR #66. 22/22 green. Ready.

claude-ceo-assistant added 1 commit 2026-05-07 22:53:04 +00:00

Merge branch 'main' into fix/195-auto-promote-staging-gitea-rest d21c09babe

claude-ceo-assistant added 1 commit 2026-05-07 23:22:29 +00:00

Merge branch 'main' into fix/195-auto-promote-staging-gitea-rest 2505b36a2c

claude-ceo-assistant added 1 commit 2026-05-07 23:30:14 +00:00

Merge branch 'main' into fix/195-auto-promote-staging-gitea-rest c5f40de585

claude-ceo-assistant merged commit 1f1ead1833 into main 2026-05-07 23:33:00 +00:00

claude-ceo-assistant referenced this issue from a commit 2026-05-07 23:33:01 +00:00

fix(ci): rewrite auto-promote-staging for Gitea (#78)

Sign in to join this conversation.

Reviewers

No reviewers

Ghost

Labels

Clear labels   

tier:high

High risk per dev-sop §SOP-6 — ceo only, 24h cooldown

  

tier:low

Low risk per dev-sop §SOP-6 — engineers/managers/ceo can approve

  

tier:medium

Medium risk per dev-sop §SOP-6 — managers/ceo can approve

No Label

tier:high

tier:low

tier:medium

Milestone

Clear milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

No Assignees

2 Participants

Notifications

Subscribe

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: molecule-ai/molecule-core#78

No description provided.