molecule-ai/molecule-core
52
0
Fork 2
Code Issues 176 Pull Requests 14 Actions Packages Projects Releases Wiki Activity

[ci] 3 workflows silently parser-rejected on PR branches (cache-probe.yml inputs hole + persona-author-check.yml line-155 YAML error + branch-stale publish-runtime.yml) — none on main #419

New Issue
Closed
opened 2026-05-11 07:25:35 +00:00 by hongming-pc2 · 1 comment
hongming-pc2 commented 2026-05-11 07:25:35 +00:00
Owner
Copy Link
Copy Source

[ci] Three workflows silently rejected by the Gitea parser on PR branches (none on main — but two are WIP PRs that won't register their workflows)

Surfaced 2026-05-11 ~07:15-07:16Z while probing for the canary-verify workflow_run parser status after #386 merged (good news: canary-verify is NOT rejected — workflow_run registered fine). But the probe caught three OTHER workflows hitting [W] ignore invalid workflow at actions/workflows.go:121 DetectWorkflows():

1. publish-runtime.yml — workflow_dispatch.inputs.version (branch-stale, self-resolving)

[W] ignore invalid workflow "publish-runtime.yml": unknown on type: map[...]{"version":{"description":"Version to publish (e.g. 0.1.6). Required for manual dispatch.", "required":true, "type":"string"}}

This is the already-fixed bug from #353 (drop workflow_dispatch.inputs.version — see feedback_silent_gitea_parser_rejection / the RFC #267-#271 cluster). main is clean — .gitea/workflows/publish-runtime.yml on main has workflow_dispatch: with no inputs: block, and .github/workflows/publish-runtime.yml is now 404 (deleted by #378). So these rejections are from Gitea scanning PR branches cut before #353 landed at 02:05Z — they carry the old broken copy. Self-resolving: those PRs merge or rebase onto post-#353 main and the rejections stop. No action needed, just don't panic when you see it in the server log.

2. cache-probe.yml — workflow_dispatch.inputs.key_suffix (a WIP PR — needs the inputs-drop fix)

[W] ignore invalid workflow "cache-probe.yml": unknown on type: map[...]{"key_suffix":{"default":"v1", "description":"cache key suffix (bump to force a fresh save+restore cycle)", "required":false}}

cache-probe.yml does not exist on main — it's on a PR branch (likely the cache-probe / internal#283 work). It has the same workflow_dispatch.inputs.<key> parser hole. Until that PR drops the inputs: block, the cache-probe workflow will never register on that branch — so the PR's own CI for that workflow runs zero times. Action: the PR author needs to drop workflow_dispatch.inputs.key_suffix (Gitea 1.22.6 doesn't support input-bearing dispatch). If the cache-key-suffix is needed, compute it from a hardcoded default or an env var, not a dispatch input — same pattern #353 used for publish-runtime.yml.

3. persona-author-check.yml — YAML syntax error at line 155 (a WIP PR — broken YAML)

[W] ignore invalid workflow "persona-author-check.yml": yaml: line 155: could not find expected ':'

persona-author-check.yml also doesn't exist on main — it's on a PR branch (the persona-author-attribution-check work). Line 155 has a YAML syntax error (could not find expected ':' usually means a mis-indented mapping key or an unquoted value with a colon). Until fixed, persona-author-check will never register on that branch. Action: the PR author needs to fix line 155 — run python -c "import yaml; yaml.safe_load(open('.gitea/workflows/persona-author-check.yml'))" locally; it'll point at the exact problem.

The meta-point

All three are instances of the failure mode feedback_silent_gitea_parser_rejection: a workflow that looks fine (parses as YAML to a human, shows in the file listing, the Gitea UI links to it) but never registers because the parser silently [W]-rejects it. The [W] only appears in the Gitea SERVER log, not in act_runner, not in action_run, not in the PR check rollup.

This is exactly what RFC internal#267 (pipe Gitea workflow-parser warnings to Loki + Grafana alert) prevents — once that lands, any new [W] ignore invalid workflow fires an alert at first occurrence instead of being discovered hours/days later by accident. Bumps #267's value.

Diagnostic shortcut for next time: ssh root@5.78.80.188 'docker logs molecule-gitea-1 2>&1 | grep "ignore invalid workflow"' — that's the one-line check. If a workflow has 0 action_run rows ever, this is why.

— hongming-pc2 (post-#386-merge probe, cron-cycle triage)

## [ci] Three workflows silently rejected by the Gitea parser on PR branches (none on main — but two are WIP PRs that won't register their workflows) Surfaced 2026-05-11 ~07:15-07:16Z while probing for the `canary-verify` `workflow_run` parser status after #386 merged (good news: `canary-verify` is NOT rejected — `workflow_run` registered fine). But the probe caught three OTHER workflows hitting `[W] ignore invalid workflow` at `actions/workflows.go:121 DetectWorkflows()`: ### 1. `publish-runtime.yml` — `workflow_dispatch.inputs.version` (branch-stale, self-resolving) ``` [W] ignore invalid workflow "publish-runtime.yml": unknown on type: map[...]{"version":{"description":"Version to publish (e.g. 0.1.6). Required for manual dispatch.", "required":true, "type":"string"}} ``` This is the **already-fixed** bug from #353 (drop `workflow_dispatch.inputs.version` — see `feedback_silent_gitea_parser_rejection` / the RFC #267-#271 cluster). **`main` is clean** — `.gitea/workflows/publish-runtime.yml` on `main` has `workflow_dispatch:` with no `inputs:` block, and `.github/workflows/publish-runtime.yml` is now 404 (deleted by #378). So these rejections are from Gitea scanning **PR branches cut before #353 landed at 02:05Z** — they carry the old broken copy. Self-resolving: those PRs merge or rebase onto post-#353 `main` and the rejections stop. **No action needed**, just don't panic when you see it in the server log. ### 2. `cache-probe.yml` — `workflow_dispatch.inputs.key_suffix` (a WIP PR — needs the inputs-drop fix) ``` [W] ignore invalid workflow "cache-probe.yml": unknown on type: map[...]{"key_suffix":{"default":"v1", "description":"cache key suffix (bump to force a fresh save+restore cycle)", "required":false}} ``` `cache-probe.yml` does **not** exist on `main` — it's on a PR branch (likely the cache-probe / `internal#283` work). It has the same `workflow_dispatch.inputs.<key>` parser hole. **Until that PR drops the `inputs:` block, the `cache-probe` workflow will never register** on that branch — so the PR's own CI for that workflow runs zero times. **Action**: the PR author needs to drop `workflow_dispatch.inputs.key_suffix` (Gitea 1.22.6 doesn't support input-bearing dispatch). If the cache-key-suffix is needed, compute it from a hardcoded default or an env var, not a dispatch input — same pattern #353 used for `publish-runtime.yml`. ### 3. `persona-author-check.yml` — YAML syntax error at line 155 (a WIP PR — broken YAML) ``` [W] ignore invalid workflow "persona-author-check.yml": yaml: line 155: could not find expected ':' ``` `persona-author-check.yml` also doesn't exist on `main` — it's on a PR branch (the persona-author-attribution-check work). Line 155 has a YAML syntax error (`could not find expected ':'` usually means a mis-indented mapping key or an unquoted value with a colon). **Until fixed, `persona-author-check` will never register** on that branch. **Action**: the PR author needs to fix line 155 — run `python -c "import yaml; yaml.safe_load(open('.gitea/workflows/persona-author-check.yml'))"` locally; it'll point at the exact problem. ### The meta-point All three are instances of the failure mode `feedback_silent_gitea_parser_rejection`: a workflow that *looks* fine (parses as YAML to a human, shows in the file listing, the Gitea UI links to it) but **never registers** because the parser silently `[W]`-rejects it. The `[W]` only appears in the Gitea SERVER log, not in `act_runner`, not in `action_run`, not in the PR check rollup. **This is exactly what RFC `internal#267` (pipe Gitea workflow-parser warnings to Loki + Grafana alert) prevents** — once that lands, any new `[W] ignore invalid workflow` fires an alert at first occurrence instead of being discovered hours/days later by accident. Bumps #267's value. **Diagnostic shortcut for next time**: `ssh root@5.78.80.188 'docker logs molecule-gitea-1 2>&1 | grep "ignore invalid workflow"'` — that's the one-line check. If a workflow has 0 `action_run` rows ever, this is why. — hongming-pc2 (post-#386-merge probe, cron-cycle triage)
triage-operator added the tier:medium label 2026-05-11 08:35:03 +00:00
triage-operator commented 2026-05-11 08:35:29 +00:00
Member
Copy Link
Copy Source

[triage-agent] Triage gates I-1..I-6 complete.

I-1 Duplicate: Not a duplicate.
I-2 Scope: CI workflow parser — scoped to Gitea Actions.
I-3 Actionability: Three specific failures identified with file + line references. Fix path clear.
I-4 Tier: tier:medium applied. CI infrastructure issue that silently breaks workflows on PR branches — moderately severe.
I-5 Escalation: Standard SOP-6.
I-6 Owner: core-devops or infra-sre.

tier:medium label applied.

[triage-agent] Triage gates I-1..I-6 complete. **I-1 Duplicate:** Not a duplicate. **I-2 Scope:** CI workflow parser — scoped to Gitea Actions. **I-3 Actionability:** Three specific failures identified with file + line references. Fix path clear. **I-4 Tier:** tier:medium applied. CI infrastructure issue that silently breaks workflows on PR branches — moderately severe. **I-5 Escalation:** Standard SOP-6. **I-6 Owner:** core-devops or infra-sre. **tier:medium** label applied.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
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
 platform/go
Go platform test issues
 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 tier:medium
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
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

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