What would you like?
Finish what #34437 started. That PR (merged 2026-08-12) moved the Windows workflow off per-develop-merge onto a CircleCI scheduled pipeline, and the schedule was tuned on 2026-08-19 to 2×/weekday (17:00 and 23:00 UTC, Mon–Fri ≈ 43 runs/month). Two pieces remain:
- Decide the final Windows frequency. The 2026 cost review targeted ~30 runs/month (nightly). The current schedule is ~43/month. Either trim the timetable to 1×/weekday or explicitly accept 2×/weekday as the standing cadence and close this out.
- Move the remaining platform workflows (
darwin-x64, darwin-arm64, linux-arm64) onto the same scheduled model. They still run on every develop merge via full-workflow-filters. This leg is about self-hosted macOS capacity and signal quality, not credits (see below).
linux-x64 stays per-push. release/* and electron/* branches keep full per-push platform coverage, unchanged.
Why is this needed?
Mostly it already was — and the numbers confirm the approach works. Measured from CircleCI Insights (workflow windows, all runs):
| Period |
develop runs |
develop credits run-rate |
| June |
102/mo |
~6–7M/mo |
| July |
110/mo |
~7M/mo |
| Aug 1–19 (pre-tuning) |
~5–8/day |
~7.3M/mo |
| Since Aug 20 (2×/weekday cron) |
exactly 2/weekday, 0 weekends |
~2.1M/mo |
The cron migration is already saving ~5M credits/month on develop-branch Windows runs alone. The remaining headroom from trimming 43 → ~30 runs/month is ~0.6M/month.
For the other platforms: macOS workflows bill zero credits (leased self-hosted hardware), and linux-arm64 is negligible in credits (~29K/month for ~141 develop runs). Scheduling them buys freed macOS hardware capacity and a coherent platform-signal model — one nightly platform sweep instead of per-merge noise (develop currently passes 47 of 213 runs, so per-merge platform signal is already unactionable) — not meaningful credit savings.
Other
This finishes action 1 of the internal CI cost report (2026-08-31, "The CI Wedge"). Note the report's ~6.0M/month estimate for this action was computed on a 30-day window that straddled the Aug-19 schedule tuning; most of that saving is now already realized. The open decision is the quality model: platform-specific regressions on develop surface within ~12–24 hours instead of per-merge, with the release-branch gate still catching anything before it ships. That decision was implicitly made when #34437 merged; this issue makes it explicit and applies it consistently across platforms.
Attn Agents:
Mechanism. Windows is done: the windows workflow (.circleci/src/pipeline/workflows/@main.yml:617-628) runs when run-windows-workflow is true (declared .circleci/config.yml:27-31), set by the CircleCI Scheduled Pipeline "Windows Develop Branch Schedule" (id 40ddfea0-34c3-47ab-8557-6bdb150b4d8d, created 2026-08-12, updated 2026-08-19; timetable: hours 17+23 UTC, Mon–Fri, branch develop). Landed via #34437 (commit 0d85fdc912). The remaining platform workflows still use &full-workflow-filters (@main.yml:2-13, runs on every develop push): linux-arm64 (:455), darwin-x64 (:516), darwin-arm64 (:566). .circleci/src compiles to .circleci/packed/pipeline.yml via scripts/pack-ci.sh --all; note the src-checksum cache (.circleci/config.yml:84-111).
Evidence. Insights API, workflow windows, all branches: monthly totals Jun 141 runs / 6.05M credits, Jul 247 / 8.67M, Aug 275 / 9.70M; develop-only runs 102 / 110 / 113 (the report's "~111×/month" = develop runs, verified). Develop credits: Aug 1–19 = 4.62M over 19 days (~7.3M/mo rate); Aug 20–Sep 2 = 987K over 14 days (~2.1M/mo rate). Since Aug 20 develop shows exactly 2 runs/weekday, 0 weekend runs — the schedule is the only remaining develop trigger. Non-develop windows runs since Aug 20: release/16.0.0 (9 runs / 364K), update-v8-snapshot-cache-on-develop (8 / 51K), personal branches via manual param (~19 / 350K) — all legitimate. linux-arm64 since Aug 1: 250 runs / 28.7K credits (cheap executors) — scheduling it is about consistency, not spend.
Fix design. (1) Windows frequency: settings-only — edit the scheduled pipeline timetable via PATCH /api/v2/schedule/40ddfea0-34c3-47ab-8557-6bdb150b4d8d (or UI) to 1×/weekday if the ~30/mo target is confirmed. Document the schedule's existence and owner in .circleci/AGENTS.md — it is invisible in-repo today. (2) Platforms: mirror the #34437 pattern — add a run-platform-workflows boolean parameter to .circleci/config.yml and .circleci/src/pipeline/@pipeline.yml, change the three platform workflows' when: from *full-workflow-filters to run-platform-workflows == true OR release/* OR electron/* OR update-v8-snapshot-cache-on-develop (drop only plain develop), and add a scheduled pipeline setting the parameter on develop — either the existing Windows schedule (rename it, set both params) or a sibling schedule at the same timetable.
Constraints. Keep update-v8-snapshot-cache-on-develop in all platform filters — it exists to fully test v8 snapshot cache updates (@main.yml:5-6). Keep force-persist-artifacts as an escape hatch (@main.yml:13). The darwin/linux-arm64 workflows contain create-*-artifacts / publish-adjacent jobs — their cadence interacts with the release-only-signing issue; if that lands first, those jobs are release-gated anyway. Scheduled pipelines are project settings, not code: the schedule change needs someone with project-settings access, and the PR should link the schedule id.
Fallback. If 1×/weekday is rejected, keep 2×/weekday everywhere — the consistency win (all platforms on one schedule) stands, and the forfeited ~0.6M/mo is small against the ~5M already realized.
Verification plan. (a) Push a no-op commit to develop: only linux-x64 (and PR-independent jobs) run. (b) Manually trigger the schedule: windows + darwin-x64 + darwin-arm64 + linux-arm64 all run end-to-end. (c) Push to release/* (or force-persist-artifacts=true): all platform workflows run per-push. (d) After two weeks, Insights should show develop platform runs = schedule count exactly, and windows develop credits at or under the ~2.1M/mo current rate (~1.1M/mo if trimmed to 1×/weekday).
Interim mitigation. Already live for Windows since Aug 20. On-demand platform runs: Trigger Pipeline with run-windows-workflow=true (and the new platform parameter once added).
What would you like?
Finish what #34437 started. That PR (merged 2026-08-12) moved the Windows workflow off per-develop-merge onto a CircleCI scheduled pipeline, and the schedule was tuned on 2026-08-19 to 2×/weekday (17:00 and 23:00 UTC, Mon–Fri ≈ 43 runs/month). Two pieces remain:
darwin-x64,darwin-arm64,linux-arm64) onto the same scheduled model. They still run on every develop merge viafull-workflow-filters. This leg is about self-hosted macOS capacity and signal quality, not credits (see below).linux-x64stays per-push.release/*andelectron/*branches keep full per-push platform coverage, unchanged.Why is this needed?
Mostly it already was — and the numbers confirm the approach works. Measured from CircleCI Insights (workflow
windows, all runs):The cron migration is already saving ~5M credits/month on develop-branch Windows runs alone. The remaining headroom from trimming 43 → ~30 runs/month is ~0.6M/month.
For the other platforms: macOS workflows bill zero credits (leased self-hosted hardware), and
linux-arm64is negligible in credits (~29K/month for ~141 develop runs). Scheduling them buys freed macOS hardware capacity and a coherent platform-signal model — one nightly platform sweep instead of per-merge noise (develop currently passes 47 of 213 runs, so per-merge platform signal is already unactionable) — not meaningful credit savings.Other
This finishes action 1 of the internal CI cost report (2026-08-31, "The CI Wedge"). Note the report's ~6.0M/month estimate for this action was computed on a 30-day window that straddled the Aug-19 schedule tuning; most of that saving is now already realized. The open decision is the quality model: platform-specific regressions on develop surface within ~12–24 hours instead of per-merge, with the release-branch gate still catching anything before it ships. That decision was implicitly made when #34437 merged; this issue makes it explicit and applies it consistently across platforms.
Attn Agents:
Mechanism. Windows is done: the
windowsworkflow (.circleci/src/pipeline/workflows/@main.yml:617-628) runs whenrun-windows-workflowis true (declared.circleci/config.yml:27-31), set by the CircleCI Scheduled Pipeline "Windows Develop Branch Schedule" (id40ddfea0-34c3-47ab-8557-6bdb150b4d8d, created 2026-08-12, updated 2026-08-19; timetable: hours 17+23 UTC, Mon–Fri, branch develop). Landed via #34437 (commit0d85fdc912). The remaining platform workflows still use&full-workflow-filters(@main.yml:2-13, runs on every develop push):linux-arm64(:455),darwin-x64(:516),darwin-arm64(:566)..circleci/srccompiles to.circleci/packed/pipeline.ymlviascripts/pack-ci.sh --all; note the src-checksum cache (.circleci/config.yml:84-111).Evidence. Insights API, workflow
windows, all branches: monthly totals Jun 141 runs / 6.05M credits, Jul 247 / 8.67M, Aug 275 / 9.70M; develop-only runs 102 / 110 / 113 (the report's "~111×/month" = develop runs, verified). Develop credits: Aug 1–19 = 4.62M over 19 days (~7.3M/mo rate); Aug 20–Sep 2 = 987K over 14 days (~2.1M/mo rate). Since Aug 20 develop shows exactly 2 runs/weekday, 0 weekend runs — the schedule is the only remaining develop trigger. Non-develop windows runs since Aug 20:release/16.0.0(9 runs / 364K),update-v8-snapshot-cache-on-develop(8 / 51K), personal branches via manual param (~19 / 350K) — all legitimate.linux-arm64since Aug 1: 250 runs / 28.7K credits (cheap executors) — scheduling it is about consistency, not spend.Fix design. (1) Windows frequency: settings-only — edit the scheduled pipeline timetable via
PATCH /api/v2/schedule/40ddfea0-34c3-47ab-8557-6bdb150b4d8d(or UI) to 1×/weekday if the ~30/mo target is confirmed. Document the schedule's existence and owner in.circleci/AGENTS.md— it is invisible in-repo today. (2) Platforms: mirror the #34437 pattern — add arun-platform-workflowsboolean parameter to.circleci/config.ymland.circleci/src/pipeline/@pipeline.yml, change the three platform workflows'when:from*full-workflow-filterstorun-platform-workflows == true OR release/* OR electron/* OR update-v8-snapshot-cache-on-develop(drop only plain develop), and add a scheduled pipeline setting the parameter on develop — either the existing Windows schedule (rename it, set both params) or a sibling schedule at the same timetable.Constraints. Keep
update-v8-snapshot-cache-on-developin all platform filters — it exists to fully test v8 snapshot cache updates (@main.yml:5-6). Keepforce-persist-artifactsas an escape hatch (@main.yml:13). The darwin/linux-arm64 workflows containcreate-*-artifacts/ publish-adjacent jobs — their cadence interacts with the release-only-signing issue; if that lands first, those jobs are release-gated anyway. Scheduled pipelines are project settings, not code: the schedule change needs someone with project-settings access, and the PR should link the schedule id.Fallback. If 1×/weekday is rejected, keep 2×/weekday everywhere — the consistency win (all platforms on one schedule) stands, and the forfeited ~0.6M/mo is small against the ~5M already realized.
Verification plan. (a) Push a no-op commit to develop: only
linux-x64(and PR-independent jobs) run. (b) Manually trigger the schedule: windows + darwin-x64 + darwin-arm64 + linux-arm64 all run end-to-end. (c) Push torelease/*(orforce-persist-artifacts=true): all platform workflows run per-push. (d) After two weeks, Insights should show develop platform runs = schedule count exactly, and windows develop credits at or under the ~2.1M/mo current rate (~1.1M/mo if trimmed to 1×/weekday).Interim mitigation. Already live for Windows since Aug 20. On-demand platform runs: Trigger Pipeline with
run-windows-workflow=true(and the new platform parameter once added).