molecule-ai/molecule-core
52
0
Fork 2
Code Issues 184 Pull Requests 16 Actions 3 Packages Projects Releases Wiki Activity

publish-runtime.yml has never fired since the 2026-05-10 .gitea port — paths+tags in same on.push interferes #351

New Issue
Closed
opened 2026-05-11 01:29:00 +00:00 by claude-ceo-assistant · 1 comment
claude-ceo-assistant commented 2026-05-11 01:29:00 +00:00
Owner
Copy Link
Copy Source

Evidence

SELECT count(*) FROM action_run WHERE workflow_id='publish-runtime.yml' AND repo_id=molecule-core;
→ 0 rows. Ever.
  • PyPI latest: 0.1.129
  • Gitea latest runtime tag: runtime-v1.0.0 (pushed before the .gitea port; never published)
  • Most recent tag attempt: runtime-v0.1.130 (pushed 2026-05-11 ~01:23Z, no workflow run dispatched, action_run for refs/tags/runtime-v0.1.130 is empty)
  • All OTHER workflows in this repo ARE firing normally (sop-tier-check, secret-scan, audit-force-merge fired multiple times in same 5-min window)
  • workflow_dispatch API endpoint /repos/.../actions/workflows/{file}/dispatches returns HTTP 404 on Gitea 1.22.6 — no programmatic dispatch fallback either

Hypothesis

The workflow on: block (after #349 merge) bundles three filters under a single push key:

on:
  push:
    branches: [main, staging]
    paths: ["workspace/**"]
    tags: ["runtime-v*"]

GitHub Actions semantics: branches+paths are AND, tags is OR (separate event-shape). The paths filter is NOT evaluated for tag pushes per GitHub docs.

Gitea Actions appears to evaluate paths against tag pushes too (no path diff vs anything → fails the filter → workflow skipped). Same effect would have hit the runtime-v1.0.0 tag before #349 was merged, but back then the file only had tags: — and that ALSO has 0 runs in DB, so the bug may be deeper than the paths interaction (could be tag-push events not dispatched at all for this workflow path).

Proposed fix

Split into two workflow files:

  • .gitea/workflows/publish-runtime.yml — revert to on.push.tags + workflow_dispatch only (no branches/paths). This is the ORIGINAL pre-port shape.
  • .gitea/workflows/publish-runtime-autobump.yml (NEW) — on.push.branches:[main,staging]+paths:[workspace/**], computes next PyPI version, pushes runtime-v$VERSION tag. The tag push then triggers publish-runtime.yml via its own on.push.tags trigger.

This decouples the two triggers so the Gitea evaluator never has to disambiguate paths-vs-tags.

Acceptance

  • After PR merges: push a no-op commit under workspace/. Observe publish-runtime-autobump.yml fire, compute 0.1.130, push tag, then observe publish-runtime.yml fire on the tag.
  • action_run shows non-zero rows for workflow_id='publish-runtime.yml'.
  • PyPI shows 0.1.130 published.

Refs: molecule-core#348 (the unblock issue), molecule-core#349 (the trigger restore that exposed this)

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

## Evidence ``` SELECT count(*) FROM action_run WHERE workflow_id='publish-runtime.yml' AND repo_id=molecule-core; → 0 rows. Ever. ``` - PyPI latest: `0.1.129` - Gitea latest runtime tag: `runtime-v1.0.0` (pushed before the .gitea port; never published) - Most recent tag attempt: `runtime-v0.1.130` (pushed 2026-05-11 ~01:23Z, no workflow run dispatched, action_run for refs/tags/runtime-v0.1.130 is empty) - All OTHER workflows in this repo ARE firing normally (sop-tier-check, secret-scan, audit-force-merge fired multiple times in same 5-min window) - workflow_dispatch API endpoint `/repos/.../actions/workflows/{file}/dispatches` returns HTTP 404 on Gitea 1.22.6 — no programmatic dispatch fallback either ## Hypothesis The workflow `on:` block (after #349 merge) bundles three filters under a single `push` key: ```yaml on: push: branches: [main, staging] paths: ["workspace/**"] tags: ["runtime-v*"] ``` GitHub Actions semantics: branches+paths are AND, tags is OR (separate event-shape). The `paths` filter is NOT evaluated for tag pushes per GitHub docs. Gitea Actions appears to evaluate `paths` against tag pushes too (no path diff vs anything → fails the filter → workflow skipped). Same effect would have hit the `runtime-v1.0.0` tag before #349 was merged, but back then the file only had `tags:` — and that ALSO has 0 runs in DB, so the bug may be deeper than the paths interaction (could be tag-push events not dispatched at all for this workflow path). ## Proposed fix Split into two workflow files: - `.gitea/workflows/publish-runtime.yml` — revert to `on.push.tags` + `workflow_dispatch` only (no branches/paths). This is the ORIGINAL pre-port shape. - `.gitea/workflows/publish-runtime-autobump.yml` (NEW) — `on.push.branches:[main,staging]+paths:[workspace/**]`, computes next PyPI version, pushes `runtime-v$VERSION` tag. The tag push then triggers `publish-runtime.yml` via its own `on.push.tags` trigger. This decouples the two triggers so the Gitea evaluator never has to disambiguate paths-vs-tags. ## Acceptance - [ ] After PR merges: push a no-op commit under `workspace/`. Observe `publish-runtime-autobump.yml` fire, compute `0.1.130`, push tag, then observe `publish-runtime.yml` fire on the tag. - [ ] `action_run` shows non-zero rows for `workflow_id='publish-runtime.yml'`. - [ ] PyPI shows `0.1.130` published. Refs: molecule-core#348 (the unblock issue), molecule-core#349 (the trigger restore that exposed this) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
claude-ceo-assistant commented 2026-05-11 01:49:07 +00:00
Author
Owner
Copy Link
Copy Source

Root cause UPDATE (2026-05-11 01:45Z)

The paths-vs-tags hypothesis (this issue body) was wrong. Actual root cause is in the Gitea server logs:

[W] ignore invalid workflow "publish-runtime.yml": unknown on type:
    map["version":{"description":...,"required":true,"type":"string"}]

Gitea 1.22.6 mis-parses workflow_dispatch.inputs.version — it flattens the inputs sub-keys into top-level on: event types and rejects the workflow. The whole file never registers, so NOTHING triggers it (not branch+paths, not tags, not workflow_dispatch).

Hongming-pc surfaced the clue: tag pushes worked at git layer but only some workflows fired. Survey showed docker/build-push-action has tag-event runs working fine — Gitea CAN dispatch tag events. So the bug was workflow-file-specific.

Fix in #353: drop inputs: from workflow_dispatch. Gitea 1.22.6 supports no-input dispatch only.

PR #352 (paths-vs-tags split) was a red herring — kept for structural clarity but did NOT fix the actual problem.

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

## Root cause UPDATE (2026-05-11 01:45Z) The paths-vs-tags hypothesis (this issue body) was wrong. Actual root cause is in the Gitea server logs: ``` [W] ignore invalid workflow "publish-runtime.yml": unknown on type: map["version":{"description":...,"required":true,"type":"string"}] ``` Gitea 1.22.6 mis-parses `workflow_dispatch.inputs.version` — it flattens the inputs sub-keys into top-level `on:` event types and rejects the workflow. The whole file never registers, so NOTHING triggers it (not branch+paths, not tags, not workflow_dispatch). Hongming-pc surfaced the clue: tag pushes worked at git layer but only some workflows fired. Survey showed `docker/build-push-action` has tag-event runs working fine — Gitea CAN dispatch tag events. So the bug was workflow-file-specific. Fix in #353: drop `inputs:` from `workflow_dispatch`. Gitea 1.22.6 supports no-input dispatch only. PR #352 (paths-vs-tags split) was a red herring — kept for structural clarity but did NOT fix the actual problem. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
approved
area/ci
CI/CD pipeline issues
 do-not-auto-merge
Opt out of autonomous merge-queue merging
 do-not-merge
hold from auto-merge (design review in progress)
 kind/infrastructure
Infrastructure-related issues
 merge-queue
Ready for serialized Gitea merge queue
 merge-queue-hold
Temporarily hold PR in merge queue
 needs-engineer
platform/go
Go platform test issues
 ready-to-build
release-blocker
Blocks the staging→main promotion / a release
 release-test
security
test-label-sre
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
 triage-test
test
 wip
Work in progress — do not auto-merge
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent-dev-a agent-dev-b agent-pm agent-researcher agent-reviewer agent-reviewer-1 agent-reviewer-cr2 app-fe (Molecule AI · app-fe) app-lead (Molecule AI · app-lead) app-qa (Molecule AI · app-qa) claude-ceo-assistant claude-ci-reader claude-status-reaper core-be (Molecule AI · core-be) core-devops (Molecule AI · core-devops) core-fe (Molecule AI · core-fe) core-lead (Molecule AI · core-lead) core-offsec (Molecule AI · core-offsec) core-qa (Molecule AI · core-qa) core-security (Molecule AI · core-security) core-uiux (Molecule AI · core-uiux) cp-be (Molecule AI · cp-be) cp-lead (Molecule AI · cp-lead) cp-qa (Molecule AI · cp-qa) cp-security (Molecule AI · cp-security) cui (Zhanlin Cui) dev-lead (Molecule AI · dev-lead) devops-engineer documentation-specialist (Molecule AI · documentation-specialist) fullstack-engineer (Molecule AI · fullstack-engineer) godwin hongming hongming-ceo-delegated hongming-codex-laptop hongming-kimi-laptop hongming-pc2 hongming-personal infra-lead (Molecule AI · infra-lead) infra-runtime-be (Molecule AI · infra-runtime-be) infra-sre (Molecule AI · infra-sre) integration-tester (Molecule AI · integration-tester) mc-drift-bot molecule-code-reviewer plugin-dev (Molecule AI · plugin-dev) pm publish-runtime-bot pypi-publisher (Molecule AI PyPI Publisher (RFC#596)) release-manager (Molecule AI · release-manager) sdk-dev (Molecule AI · sdk-dev) sdk-lead (Molecule AI · sdk-lead) sop-drift-bot sop-tier-bot (SOP Tier-Check Bot) technical-writer (Molecule AI · technical-writer) triage-operator (Molecule AI · triage-operator)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: molecule-ai/molecule-core#351
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?