Skip to content

ci: cmux-tui artifact publishing runs in its own artifacts environment - #16267

Merged
lawrencecchen merged 2 commits into
mainfrom
fix-cmux-tui-artifacts-env
Sep 30, 2026
Merged

lawrencecchen merged 2 commits into
mainfrom
fix-cmux-tui-artifacts-env

Conversation

@lawrencecchen

@lawrencecchen lawrencecchen commented Sep 30, 2026 •

Copy link
Copy Markdown
Contributor

#16171 put the cmux-tui publish job in the `release` environment. That policy allows only `main` and `v*` tags, so publishes from cmux-next helper branches (`cmux-tui-pin-*`) failed before any step ran (run 36779595430).

A commit-addressed cmux-tui build is not a production release. The job now runs in a new `artifacts` environment. Its deployment policy (already configured) allows `main`, `feat-cmux-next` and `cmux-tui-pin-`. The job uses only the three `CF_R2_` upload secrets; signing, Sparkle, Homebrew and Apple secrets stay in `release`. The guard test checks the environment and that the job reads no other secret.

Commit 1 adds the failing guard, commit 2 the fix. `tests/test_ci_production_secrets_protected_env.py` passes locally.

Changelog

none

🤖 Generated with Claude Code


View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.


Summary by cubic

Fixes cmux-tui artifact publishing so daemon pin builds from helper branches can upload to R2 again.

  • The publish job now runs in a new artifacts environment whose deployment policy allows main, feat-cmux-next, and cmux-tui-pin-* branches; the release environment only allows main and v* tags, which blocked pin publishes before any step ran.
  • The artifacts environment holds only the three CF_R2_* upload secrets; signing, Sparkle, Homebrew, and Apple secrets stay in release.
  • Adds a guard test that the publish job runs in the artifacts environment and reads no secrets other than the R2 upload credentials.

Written for commit fa3bedb. Summary will update on new commits.

Review in cubic

Summary by CodeRabbit

  • Chores
    • Improved security controls for publishing build artifacts. No user-facing functionality changes.

lawrencecchen and others added 2 commits September 30, 2026 15:46
…ronment

#16171 put the cmux-tui publish job in the release environment, whose
policy allows only main and v* tags, so helper-branch pin publishes
fail before any step runs.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The artifacts environment holds only the R2 upload credentials and
allows main, feat-cmux-next and cmux-tui-pin-* helper branches, so
daemon pin publishes work again while signing, Sparkle, Homebrew and
Apple secrets stay in release (main and v* tags only).

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

Copy link
Copy Markdown
Contributor

All contributors have signed the CLA ✍️ ✅
Posted by the CLA Assistant Lite bot.

@coderabbitai

coderabbitai Bot commented Sep 30, 2026

Copy link
Copy Markdown

Review in Change Stack →

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

Note

Currently processing new changes in this PR. This may take a few minutes, please wait...

⚙️ Run configuration

Configuration used: Repository: manaflow-ai/cmux/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 675a63f8-9ba5-46c4-be98-9236af8a309b

📥 Commits

Reviewing files that changed from the base of the PR and between 71bb553 and fa3bedb.

📒 Files selected for processing (2)
  • .github/workflows/cmux-tui-artifacts.yml
  • tests/test_ci_production_secrets_protected_env.py
 _____________________________________
< Please step away from the keyboard! >
 -------------------------------------
  \
   \   \
        \ /\
        ( )
      .( o ).
✨ Finishing Touches
📝 Generate docstrings
  • Commit to this branch
  • Create a new PR
🧪 Generate unit tests (beta)
  • Commit to this branch
  • Create a new PR
  • Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@lawrencecchen
lawrencecchen merged commit 02b80fe into main Sep 30, 2026
60 of 62 checks passed
@lawrencecchen
lawrencecchen deleted the fix-cmux-tui-artifacts-env branch September 30, 2026 22:50
@github-actions

Copy link
Copy Markdown
Contributor

Merge receipt for fa3bedbab5: every check was green at merge (12 verified; 17 skipped by policy). Full suite runs on main after merge.

lawrencecchen added a commit that referenced this pull request Sep 30, 2026
#16267)

* test(ci): cmux-tui artifact publishing must run in the artifacts environment

#16171 put the cmux-tui publish job in the release environment, whose
policy allows only main and v* tags, so helper-branch pin publishes
fail before any step runs.

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

* fix(ci): cmux-tui artifact publishing runs in the artifacts environment

The artifacts environment holds only the R2 upload credentials and
allows main, feat-cmux-next and cmux-tui-pin-* helper branches, so
daemon pin publishes work again while signing, Sparkle, Homebrew and
Apple secrets stay in release (main and v* tags only).

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

---------

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
rustybret pushed a commit to rustybret/bmux that referenced this pull request Sep 30, 2026
488eaf7 fix(cloud): make Cloud workspace reconciliation always settle (manaflow-ai#16158)
02b80fe ci: cmux-tui artifact publishing runs in its own artifacts environment (manaflow-ai#16267)
71bb553 ci: propagate settled fast-guard failures (manaflow-ai#16258)
3121d49 ci: fold Testbox guard checks into fast guard lane (manaflow-ai#16247)

# Conflicts:
#	.github/workflows/ci-guards.yml
#	.github/workflows/cmux-tui-artifacts.yml
#	.github/workflows/testbox-broker-guard.yml
lawrencecchen added a commit that referenced this pull request Sep 30, 2026
…ope) (#16260)

* fix: share OpenCodePaths with the CLI through CMUXAgentLaunch

#16229 made CLI/cmux.swift call OpenCodePaths, but the enum lived in
Sources/SessionIndexModels.swift, which only the app target compiles, so
the CLI target fails with "cannot find 'OpenCodePaths' in scope". Move
the unchanged path logic into CMUXAgentLaunch, which the app, the CLI and
cmuxTests already import, and make its two entry points public.

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

* Pass the temporary-config flag to the Codex provider override parser

#16201 made providerOverrides(from:) skip provider entries when the caller
uses a temporary CODEX_HOME, but read `usesTemporaryConfig`, a parameter of
build(configToml:usesTemporaryConfig:) that is not in scope there, so the CLI
no longer compiles. Pass the flag through.

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

* test: match temporary Codex config argument scope

* Make OpenCodePaths a value type to satisfy package conventions

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

* ci: cmux-tui artifact publishing runs in its own artifacts environment (#16267)

* test(ci): cmux-tui artifact publishing must run in the artifacts environment

#16171 put the cmux-tui publish job in the release environment, whose
policy allows only main and v* tags, so helper-branch pin publishes
fail before any step runs.

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

* fix(ci): cmux-tui artifact publishing runs in the artifacts environment

The artifacts environment holds only the R2 upload credentials and
allows main, feat-cmux-next and cmux-tui-pin-* helper branches, so
daemon pin publishes work again while signing, Sparkle, Homebrew and
Apple secrets stay in release (main and v* tags only).

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

---------

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

* fix(cloud): make Cloud workspace reconciliation always settle (#16158)

* test(cloud): reusing a projection at its current placement changes nothing

Reconcile reprojects every missing placement through SurfaceCatalog.project.
When the reused pane already carries that placement, attachRemoteView still
removes and reinserts it, bumps the projection revision twice, and requests
the next reconcile of the same machine. Any disagreement between the plan
and project() then becomes a main-actor livelock, which is how nightly
b36a9b3 spun at 98% CPU and grew to tens of GB (fixed at the plan level by
#16025). Fails on main: projectionVersions advances by 2.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* fix(cloud): reattaching a projection's current placement is a no-op

attachRemoteView rewrote a reused projection even when its remote workspace
and tab were already the requested ones: it removed and reinserted it
(clearing and resetting the panel directory, rerunning sidebar git probes,
bumping the guest routing revision twice) and requested another reconcile of
the machine. Since reconcile itself reprojects through project(), any plan
that reports a shown pane as missing became an endless main-actor loop.

Return early when the coordinates are unchanged, and apply a real change as
one projections assignment so observers never see the pane unprojected.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* fix(cloud): setting a projection's current remote placement is a no-op

Same guard as attachRemoteView for setRemotePlacement: skip views whose
coordinates already match, and apply real changes as one projections
assignment. Unchanged placements no longer bump the projection revision or
post a catalog change that wakes the device layout coordinator. The test now
states its fixture precondition explicitly.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* test(cloud): reconciling one graph stops when every pass requests another

A consumer that requests another reconcile without changing the accepted
graph keeps CloudWorkspaceProjectionCoordinator's loop running forever on
the main actor, which is how nightly b36a9b3 hung at 100% CPU and grew to
tens of GB. Fails on main: the loop runs until the test stub stops asking
(1000 passes).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* fix(cloud): bound reconciliation passes over one accepted graph

CloudWorkspaceProjectionCoordinator re-ran reconcile while anything kept
requesting it, with no progress check. Any consumer that asks for another
pass without changing the graph (attachRemoteView before this PR, a plan
that reports a shown pane as missing in #16025) held the main actor forever:
nightly b36a9b3 pinned a core, grew to tens of GB, and could not even run
its updater.

Count passes over the same accepted CloudVMState. A converging graph needs
two or three; after eight, stop, report a Sentry warning, and wait for the
next graph or request, which starts a new count.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* fix(cloud): bound reconciliation by progress, not by passes over one graph

Review of the previous bound: counting every pass over an unchanged graph
could stop a reconcile that was still making progress (a staggered restore
of several bound workspaces re-requests the same graph), stranding panes
until the next graph.

CloudWorkspaceReconcileBudget now stops after three consecutive passes that
start from the same graph, projection revision and bindings (a pass that
changed nothing cannot make the next one different), with a hard ceiling of
64 passes per graph for a loop that rewrites projections every pass, as
nightly b36a9b3 did. Non-convergence is reported once per graph.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* fix(cloud): report projection non-convergence once per daemon generation

Review: keying the dedupe on the full CloudVMState retained a whole graph per
machine for the process lifetime (cancel never cleared it) and still reported
once per revision. Key on the cursor generation, include generation and
revision in the event, and clear it when the machine is cancelled.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* chore(l10n): document the French Actions discovery titles as invariant

Same change as #16175: main's localization parity check fails on
actions.discovery.menuTitle and dialogTitle (fr is identical to English),
which blocks this PR's static preflight and every gate behind it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

* fix(tests): name the app's window-chrome sidebar options explicitly

#11539 reverted #14991's qualification in SidebarWidthPolicyTests, so
SidebarMaterialOption.sidebar is ambiguous between CmuxSettings and the
app's typealias to WindowChromeSidebarMaterialOption. Use the
WindowChrome names again, as #14991 did.

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

---------

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-authored-by: Leo Li <cheerleaderleo@outlook.com>
Co-authored-by: Austin Wang <austinwang115@gmail.com>
austinywang added a commit that referenced this pull request Oct 1, 2026
…ope) (#16260)

* fix: share OpenCodePaths with the CLI through CMUXAgentLaunch

#16229 made CLI/cmux.swift call OpenCodePaths, but the enum lived in
Sources/SessionIndexModels.swift, which only the app target compiles, so
the CLI target fails with "cannot find 'OpenCodePaths' in scope". Move
the unchanged path logic into CMUXAgentLaunch, which the app, the CLI and
cmuxTests already import, and make its two entry points public.

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

* Pass the temporary-config flag to the Codex provider override parser

#16201 made providerOverrides(from:) skip provider entries when the caller
uses a temporary CODEX_HOME, but read `usesTemporaryConfig`, a parameter of
build(configToml:usesTemporaryConfig:) that is not in scope there, so the CLI
no longer compiles. Pass the flag through.

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

* test: match temporary Codex config argument scope

* Make OpenCodePaths a value type to satisfy package conventions

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

* ci: cmux-tui artifact publishing runs in its own artifacts environment (#16267)

* test(ci): cmux-tui artifact publishing must run in the artifacts environment

#16171 put the cmux-tui publish job in the release environment, whose
policy allows only main and v* tags, so helper-branch pin publishes
fail before any step runs.

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

* fix(ci): cmux-tui artifact publishing runs in the artifacts environment

The artifacts environment holds only the R2 upload credentials and
allows main, feat-cmux-next and cmux-tui-pin-* helper branches, so
daemon pin publishes work again while signing, Sparkle, Homebrew and
Apple secrets stay in release (main and v* tags only).

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

---------

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

* fix(cloud): make Cloud workspace reconciliation always settle (#16158)

* test(cloud): reusing a projection at its current placement changes nothing

Reconcile reprojects every missing placement through SurfaceCatalog.project.
When the reused pane already carries that placement, attachRemoteView still
removes and reinserts it, bumps the projection revision twice, and requests
the next reconcile of the same machine. Any disagreement between the plan
and project() then becomes a main-actor livelock, which is how nightly
b36a9b3 spun at 98% CPU and grew to tens of GB (fixed at the plan level by
#16025). Fails on main: projectionVersions advances by 2.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* fix(cloud): reattaching a projection's current placement is a no-op

attachRemoteView rewrote a reused projection even when its remote workspace
and tab were already the requested ones: it removed and reinserted it
(clearing and resetting the panel directory, rerunning sidebar git probes,
bumping the guest routing revision twice) and requested another reconcile of
the machine. Since reconcile itself reprojects through project(), any plan
that reports a shown pane as missing became an endless main-actor loop.

Return early when the coordinates are unchanged, and apply a real change as
one projections assignment so observers never see the pane unprojected.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* fix(cloud): setting a projection's current remote placement is a no-op

Same guard as attachRemoteView for setRemotePlacement: skip views whose
coordinates already match, and apply real changes as one projections
assignment. Unchanged placements no longer bump the projection revision or
post a catalog change that wakes the device layout coordinator. The test now
states its fixture precondition explicitly.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* test(cloud): reconciling one graph stops when every pass requests another

A consumer that requests another reconcile without changing the accepted
graph keeps CloudWorkspaceProjectionCoordinator's loop running forever on
the main actor, which is how nightly b36a9b3 hung at 100% CPU and grew to
tens of GB. Fails on main: the loop runs until the test stub stops asking
(1000 passes).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* fix(cloud): bound reconciliation passes over one accepted graph

CloudWorkspaceProjectionCoordinator re-ran reconcile while anything kept
requesting it, with no progress check. Any consumer that asks for another
pass without changing the graph (attachRemoteView before this PR, a plan
that reports a shown pane as missing in #16025) held the main actor forever:
nightly b36a9b3 pinned a core, grew to tens of GB, and could not even run
its updater.

Count passes over the same accepted CloudVMState. A converging graph needs
two or three; after eight, stop, report a Sentry warning, and wait for the
next graph or request, which starts a new count.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* fix(cloud): bound reconciliation by progress, not by passes over one graph

Review of the previous bound: counting every pass over an unchanged graph
could stop a reconcile that was still making progress (a staggered restore
of several bound workspaces re-requests the same graph), stranding panes
until the next graph.

CloudWorkspaceReconcileBudget now stops after three consecutive passes that
start from the same graph, projection revision and bindings (a pass that
changed nothing cannot make the next one different), with a hard ceiling of
64 passes per graph for a loop that rewrites projections every pass, as
nightly b36a9b3 did. Non-convergence is reported once per graph.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* fix(cloud): report projection non-convergence once per daemon generation

Review: keying the dedupe on the full CloudVMState retained a whole graph per
machine for the process lifetime (cancel never cleared it) and still reported
once per revision. Key on the cursor generation, include generation and
revision in the event, and clear it when the machine is cancelled.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* chore(l10n): document the French Actions discovery titles as invariant

Same change as #16175: main's localization parity check fails on
actions.discovery.menuTitle and dialogTitle (fr is identical to English),
which blocks this PR's static preflight and every gate behind it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

* fix(tests): name the app's window-chrome sidebar options explicitly

#11539 reverted #14991's qualification in SidebarWidthPolicyTests, so
SidebarMaterialOption.sidebar is ambiguous between CmuxSettings and the
app's typealias to WindowChromeSidebarMaterialOption. Use the
WindowChrome names again, as #14991 did.

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

---------

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-authored-by: Leo Li <cheerleaderleo@outlook.com>
Co-authored-by: Austin Wang <austinwang115@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant