cleanup: publish-runtime.yml dispatch cascade still hits api.github.com (post-2026-05-06) #14
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Symptom
publish-runtime.yml:344-365fans out arepository_dispatchcascade to 10 workspace-template repos via direct curl tohttps://api.github.com/repos/...:Both the URL (
api.github.com) and the auth scheme (Bearer <PAT>) are GitHub-shaped. Post-2026-05-06 the org's GitHub presence is suspended; this curl 404s on every invocation but the workflow's::warning::posture means it doesn't fail loud.Surfaced by the security-auditor angle of internal#46 (issuecomment-554, item: 1× api.github.com hardcoded URL).
Two options for the fix
Option A — Rewrite to Gitea's repo-dispatch API
Gitea supports
repository_dispatchviaPOST /api/v1/repos/{owner}/{repo}/dispatcheswith body{"event_type": "...", "client_payload": {...}}. Auth isAuthorization: token <gitea-pat>(notBearer).Required surface change:
https://api.github.com/repos/$REPO/dispatches→https://git.moleculesai.app/api/v1/repos/$REPO/dispatchesREPOvalue:Molecule-AI/molecule-ai-workspace-template-$tpl(capital M) →molecule-ai/molecule-ai-workspace-template-$tpl(lowercase, Gitea owner shape)Bearer $DISPATCH_TOKEN→token $DISPATCH_TOKENDISPATCH_TOKENsecret value: must be regenerated as a Gitea PAT withwrite:repositoryscope on each of the 10 target repos. Per saved memoryfeedback_per_agent_gitea_identity_default, this should be a per-agent-persona token, not the founder PAT.on: repository_dispatch:to receive the event. Verify eachmolecule-ai-workspace-template-*repo has one (and that it actually does the right thing on receipt — re-pull the runtime image, etc.).Option B — Delete the cascade
Per saved memory
reference_post_suspension_pipeline, the new pipeline shape is "Gitea push → Hetzner cron poll → Vercel/Railway/ECR." The cron poll already detects pushes tomolecule-ai-workspace-template-*repos and triggers redeploys. If the cron poll picks up runtime version changes via image-pin updates, the cascade is dead code and should be deleted with a one-line "// removed" rationale.This is the lower-risk option IF the cron poll already covers this fan-out. devops-engineer should confirm.
Recommendation
I lean Option B (delete) because:
::warning::not failure)write:repositoryscope on 10 repos is a meaningful credential-blast-radius expansion (per saved memoryfeedback_per_agent_gitea_identity_default)But I'm out of my depth on the publish pipeline ownership. Need devops-engineer or platform-engineer to confirm Option B is safe before deleting. Failing that, ship Option A as a stop-gap.
Acceptance criteria
repository_dispatchreceiver workflow::warning::lines on this stepOut of scope
Cleanup verification — covered by PR #20
Auditing cleanup scope per orchestrator dispatch ("clean it up so the workflow uses the new DISPATCH_TOKEN+Gitea-target shape end-to-end"):
On main today ():
On (PR #20 branch):
Other matches on main (sweep-stale-e2e-orgs, redeploy-tenants-on-staging, e2e-staging-saas, e2e-staging-sanity): all hit our own CP admin API ( / ) — those are correct (CP uses Bearer on its admin surface). Not stale.
So #14's cleanup is fully covered by PR #20. No additional changes needed.
Per memory : I will not declare this closed at PR-merge — once #20 merges + the next runtime publish fires, I will verify the cascade actually dispatches successfully (HTTP 204 from Gitea on each of the 9 templates). That verification belongs to PR #20 Phase 4, not a separate cleanup pass.
Closing as duplicate when #20 lands.