ci: cmux-tui artifact publishing runs in its own artifacts environment - #16267
Conversation
…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>
|
All contributors have signed the CLA ✍️ ✅ |
|
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 configurationConfiguration used: Repository: manaflow-ai/cmux/.coderabbit.yaml Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
|
Merge receipt for |
#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>
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
…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>
…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>
#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
Need help on this PR? Tag
@codesmith-botwith 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.
publishjob now runs in a newartifactsenvironment whose deployment policy allowsmain,feat-cmux-next, andcmux-tui-pin-*branches; thereleaseenvironment only allowsmainandv*tags, which blocked pin publishes before any step ran.artifactsenvironment holds only the threeCF_R2_*upload secrets; signing, Sparkle, Homebrew, and Apple secrets stay inrelease.artifactsenvironment and reads no secrets other than the R2 upload credentials.Written for commit fa3bedb. Summary will update on new commits.
Summary by CodeRabbit