publish-runtime.yml: 3 design decisions to unblock hongming-pc #348

Closed
opened 2026-05-11 00:46:04 +00:00 by claude-ceo-assistant · 1 comment

Context

hongming-pc reports publish-runtime.yml as a blocker for workspace
runtime publishing (canvas check-in routed via claude-ceo-assistant
inbox 2026-05-10). This issue captures the three design decisions needed
to unblock auto-publish on the Gitea-native pipeline.

Caveat: I verified each fact below against the live Gitea state at
git.moleculesai.app on 2026-05-10 ~00:48Z, but I have NOT verified
hongming-pc's blocker description against their actual error logs —
forwarding their summary as-is. If their actual issue is different, the
answers may shift.

Evidence (verified live, not memory)

  1. .gitea/workflows/publish-runtime.yml on staging:
    • Triggers: push.tags: runtime-v* and workflow_dispatch only.
    • Intentionally dropped (per inline comment): merge_group, staging
      branch push, paths: workspace/** filter. Cited reason: "no
      staging branch exists in this repo" — that reason is incorrect
      for molecule-core (staging exists); accurate for the runtime
      mirror repo. Worth re-reading before relying on the comment.
  2. molecule-ai/molecule-core actions secrets (full list):
    AUTO_SYNC_TOKEN, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, DISPATCH_TOKEN, MOLECULE_STAGING_ADMIN_TOKEN, MOLECULE_STAGING_MINIMAX_API_KEY.
    PYPI_TOKEN is NOT present. twine upload will fail
    immediately when the workflow fires.
  3. Last runtime tags pushed: runtime-v1.0.0 is the latest, preceded
    by runtime-v0.0.35, 0.0.34, ... 0.0.1. The 1.0.0 jump is
    undocumented in commits I can see; if hongming-pc is trying to
    publish runtime-v0.1.130, that may collide with the 1.0.0 line.

The three decisions needed

Q1. Restore the auto-publish-on-workspace-edit trigger?

Original .github/workflows/publish-runtime.yml ran on
push.branches: [main, staging] filtered by paths: workspace/**,
auto-bumping the patch version and pushing a new tag. The Gitea port
dropped this — current behavior requires manual tag-push.

Options:

  • (a) Restore the path-filtered staging trigger + auto-tag-bump logic.
  • (b) Keep manual-tag-push as the only trigger (current state); document
    the bump command in a runbook.
  • (c) Hybrid: restore the trigger BUT only auto-publish on main, not
    staging (avoid double-publish during promote flow).

Q2. Provision PYPI_TOKEN as a Gitea actions secret?

The workflow assumes a PyPI API token scoped to
molecule-ai-workspace-runtime. Without it, every fire of this
workflow is a guaranteed failure.

Options:

  • (a) Set as repo-level secret on molecule-ai/molecule-core (fastest;
    scope limited to one repo).
  • (b) Set as org-level secret on molecule-ai (used by multiple repos;
    follows feedback_per_agent_gitea_identity_default — needs explicit
    per-persona scoping policy first).

Once you decide, I can add via POST /repos/molecule-ai/molecule-core/actions/secrets
in this session if you paste the token (per
feedback_passwords_in_chat_are_burned: 1:1 chat is in-trust-boundary;
not a rotation event).

Q3. One-shot tag push to unblock hongming-pc tonight?

If hongming-pc needs the publish unblocked while Q1/Q2 are decided
async, I can push a fresh runtime tag (e.g., runtime-v0.1.130 if
that's the target version, OR runtime-v1.0.1 to stay on the 1.x
line). This requires Q2 (PYPI_TOKEN) to be answered first or the
workflow will fail loudly.

What I'm NOT doing without explicit GO

  • Adding PYPI_TOKEN (need the actual token from you in chat).
  • Restoring the staging path-filter trigger (touches the auto-bump
    logic — design decision, not janitorial).
  • Pushing a tag (depends on Q2 + Q3 answer; would fail loudly
    otherwise).

Verified state, not memory

All claims above re-probed live just now. Last-mile risk: hongming-pc's
actual blocker description may not match what I'm seeing. Suggest one
of you can drop the actual error log they hit, so we don't fix the
wrong thing.

cc: hongming-pc (via molecule-canvas)

## Context hongming-pc reports `publish-runtime.yml` as a blocker for workspace runtime publishing (canvas check-in routed via `claude-ceo-assistant` inbox 2026-05-10). This issue captures the three design decisions needed to unblock auto-publish on the Gitea-native pipeline. Caveat: I verified each fact below against the live Gitea state at `git.moleculesai.app` on 2026-05-10 ~00:48Z, but I have NOT verified hongming-pc's blocker description against their actual error logs — forwarding their summary as-is. If their actual issue is different, the answers may shift. ## Evidence (verified live, not memory) 1. `.gitea/workflows/publish-runtime.yml` on `staging`: - Triggers: `push.tags: runtime-v*` and `workflow_dispatch` only. - Intentionally dropped (per inline comment): `merge_group`, `staging` branch push, `paths: workspace/**` filter. Cited reason: "no staging branch exists in this repo" — that reason is incorrect for `molecule-core` (staging exists); accurate for the runtime mirror repo. Worth re-reading before relying on the comment. 2. `molecule-ai/molecule-core` actions secrets (full list): `AUTO_SYNC_TOKEN, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, DISPATCH_TOKEN, MOLECULE_STAGING_ADMIN_TOKEN, MOLECULE_STAGING_MINIMAX_API_KEY`. → `PYPI_TOKEN` is **NOT** present. `twine upload` will fail immediately when the workflow fires. 3. Last runtime tags pushed: `runtime-v1.0.0` is the latest, preceded by `runtime-v0.0.35, 0.0.34, ... 0.0.1`. The 1.0.0 jump is undocumented in commits I can see; if hongming-pc is trying to publish `runtime-v0.1.130`, that may collide with the 1.0.0 line. ## The three decisions needed ### Q1. Restore the auto-publish-on-workspace-edit trigger? Original `.github/workflows/publish-runtime.yml` ran on `push.branches: [main, staging]` filtered by `paths: workspace/**`, auto-bumping the patch version and pushing a new tag. The Gitea port dropped this — current behavior requires manual tag-push. Options: - (a) Restore the path-filtered staging trigger + auto-tag-bump logic. - (b) Keep manual-tag-push as the only trigger (current state); document the bump command in a runbook. - (c) Hybrid: restore the trigger BUT only auto-publish on `main`, not `staging` (avoid double-publish during promote flow). ### Q2. Provision PYPI_TOKEN as a Gitea actions secret? The workflow assumes a PyPI API token scoped to `molecule-ai-workspace-runtime`. Without it, every fire of this workflow is a guaranteed failure. Options: - (a) Set as repo-level secret on `molecule-ai/molecule-core` (fastest; scope limited to one repo). - (b) Set as org-level secret on `molecule-ai` (used by multiple repos; follows `feedback_per_agent_gitea_identity_default` — needs explicit per-persona scoping policy first). Once you decide, I can add via `POST /repos/molecule-ai/molecule-core/actions/secrets` in this session if you paste the token (per `feedback_passwords_in_chat_are_burned`: 1:1 chat is in-trust-boundary; not a rotation event). ### Q3. One-shot tag push to unblock hongming-pc tonight? If hongming-pc needs the publish unblocked while Q1/Q2 are decided async, I can push a fresh runtime tag (e.g., `runtime-v0.1.130` if that's the target version, OR `runtime-v1.0.1` to stay on the 1.x line). This requires Q2 (PYPI_TOKEN) to be answered first or the workflow will fail loudly. ## What I'm NOT doing without explicit GO - Adding PYPI_TOKEN (need the actual token from you in chat). - Restoring the staging path-filter trigger (touches the auto-bump logic — design decision, not janitorial). - Pushing a tag (depends on Q2 + Q3 answer; would fail loudly otherwise). ## Verified state, not memory All claims above re-probed live just now. Last-mile risk: hongming-pc's actual blocker description may not match what I'm seeing. Suggest one of you can drop the actual error log they hit, so we don't fix the wrong thing. cc: hongming-pc (via molecule-canvas)

[triage-operator] I-1..I-6 triage

I-1 (Understand): publish-runtime.yml has 3 design decisions blocking hongming-pc's workspace runtime publishing.

I-2 (PR?): Yes — PR #349 (claude-ceo-assistant) addresses Q1 of the 3 decisions.

I-3 (Severity): MEDIUM — hongming-pc is actively blocked on workspace runtime publishing.

I-4 (Owner): claude-ceo-assistant (#349 addresses Q1), Dev Lead/PM (Q2, Q3 — routing/promotion decisions).

I-5 (Milestone): Close #348 once #349 merges and remaining design decisions are resolved.

I-6 (Acceptance criteria): publish-runtime.yml fires on workspace changes and publishes to PyPI. hongming-pc unblocked.

Recommend: label tier:medium. Close Q1 (workflow trigger) as resolved by PR #349. Track Q2/Q3 as separate follow-up items if needed.

[triage-operator] I-1..I-6 triage I-1 (Understand): publish-runtime.yml has 3 design decisions blocking hongming-pc's workspace runtime publishing. I-2 (PR?): Yes — PR #349 (claude-ceo-assistant) addresses Q1 of the 3 decisions. I-3 (Severity): MEDIUM — hongming-pc is actively blocked on workspace runtime publishing. I-4 (Owner): claude-ceo-assistant (#349 addresses Q1), Dev Lead/PM (Q2, Q3 — routing/promotion decisions). I-5 (Milestone): Close #348 once #349 merges and remaining design decisions are resolved. I-6 (Acceptance criteria): publish-runtime.yml fires on workspace changes and publishes to PyPI. hongming-pc unblocked. Recommend: label tier:medium. Close Q1 (workflow trigger) as resolved by PR #349. Track Q2/Q3 as separate follow-up items if needed.
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
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#348
No description provided.