Make Studio's pull-request CI faster: proposals for review

@einari

@einari — proposals to make Studio's pull-request CI faster and cheaper. Studio CI is your area, so nothing here is implemented until you say which items you want (or object). The numbers refer to the organization CI plan they come from.

Proposed, highest value first

(15) Compile Core once per push. Frontend Smoke and CLI Parity each rebuild Core today. Reuse the Backend Specs build output and run them with --no-build, and narrow the paths that trigger CLI Parity. Expected: Frontend Smoke about 18 → 8 minutes, CLI Parity about 22 → under 5.
(16) Split the Core spec lane into two parallel lanes, after the container diagnosis in Containers are removed on the shared CI Docker host while specs use them #905. Expected: Backend Specs 7–8 minutes shorter. Risk: spec isolation and memory, so it is measured before it is kept.
(2) One yarn cache instead of five. The same yarn.lock is cached under five keys, and every pull request saves its own copy, which evicts main's. Pull requests would only restore; main (or a nightly job) saves. A cache hit makes yarn install take about 4 seconds instead of about a minute. Uses the shared cache actions once they are available.
(25) Publish builds all images in one docker buildx bake in the build job, without the build-output image round trip, keeping the cold, stateless build safeguard.
(27) Dependency Audit runs on pull requests only for backend paths, plus a nightly run on main (after checking how Publish treats a path-skipped check).
(6) Stop re-running pull-request gate checks on every push to main where main only accepts pull requests.
(10) Chronicle Health: the scheduled check fails most runs before it checks anything, while installing its tools. Fix the tooling (keep the failure semantics as they are), and consider a lower frequency.
(11, diagnostics only) Record container events during Backend Specs and upload them when the job fails, to find what removes the spec containers in Containers are removed on the shared CI Docker host while specs use them #905. Coordinated with the Containers are removed on the shared CI Docker host while specs use them #905 work.

Smaller, later: merge the six Frontend Build workflows into one; lower the Backend Specs timeout from 90 to 50 minutes once the runner fix it depends on has landed.

Not changed: Debug versus Release as separate gates, the build-once/--no-build pattern and its zero-test guards, Publish's single pending slot (no cancel-in-progress), gate jobs that must never be skipped by if: or labels, the Dependency Audit self-cancel fix, Integration Specs concurrency, and the Chronicle Health failure semantics.

Reply with the numbers you want; each one becomes its own pull request with a review before merge.

Status

State: Done — All Option A items shipped, superseded or obsolete (evidence in closing comment, verified by Sol). Approval-gated items moved to #1278.
Branch: cand/studio-20261030
Scope: Proposals posted for einari; implement only the items he approves (or unobjected after a day).
Delivered: Nothing yet.
Remaining: Adopt the shared yarn-cache action in the frontend build and the scheduled-code validation guard for code-only schedules (direction A); higher-risk policy changes need their own approval.
Follow-ups: None.

Item 3 (one yarn cache) is now concrete: the shared yarn-cache action is available in Cratis/Workflows. The proposal is to replace the hand-written yarn cache steps in Studio's reusable frontend build with that one action. Pull requests then only restore the cache; pushes to main (and a nightly or manual run on main) save it under a single key, so the five per-key copies and the pull-request-scoped entries go away. It caches Yarn's own cache folder, never node_modules. Still waiting for your OK before changing anything.

One more proposal (organization CI plan row 5): Studio runs its release-note and no-work-records pull-request checks as separate workflows. Most Cratis repositories now call one shared pull-request policy workflow from Cratis/Workflows that does both in a single job. The proposal is to replace Studio's two separate callers with that one caller, keeping Studio's own runner choice. It removes one job per pull request event and keeps the same checks. Required check names would be updated in the same change if they differ. Still waiting for your OK.

@einari

@einari, could you give an OK or a no on the two proposals above (one shared yarn cache, and the shared pull-request policy check)? You approved the same policy-check change for Direct (Cratis/Direct#1996, check name policy / verify), so Studio would match it. The branch is prepared but won't be opened until you answer.

Decision (L0, delegated by woksin): go ahead with both proposals. Replace Studio's release-note and no-work-records callers with the shared pull-request policy caller (policy / verify, the same change already approved and shipped for Direct), and adopt the shared yarn-cache action (restore on pull requests, save on main). The workflow PRs merge only when no Studio release is pending.

The shared pull-request policy check is on Studio main through Cratis/Studio#2093: pull requests now run policy / verify in place of the separate release-note and work-record checks.

The second approved proposal, the shared yarn-cache action, is not delivered yet, so this issue stays open for it.

Evidence from the October 2026 orchestration retrospective (local work records, not in the repo) for the remaining Studio CI work:

Problem. Every Studio push triggers ≈8 heavy workflows; Core Debug is built up to three times per PR; Frontend Smoke (≈13.5 min) runs on nearly every PR; 556 duplicate (workflow, SHA) runs were recorded 10-18..22. Backend Specs on PRs took 32–47 min (p90 99 min on 10-20) against ≈8 min on main, with ≈35 % cancel+fail under the CI-first regime and 49 % success under the release train, and needed three timeout-raise PRs in three days (#1779, #1835, #1928) plus 75 gh run rerun calls. Queue wait on the cratis-arc pool was demand-driven (p50 1.3 → 27 min between two mornings); the fixes that measurably helped were moving release jobs off the PR pool and a warm release runner (#2152/#2158, Infrastructure #221), not larger CPU requests or sharding.

Proposal (in addition to the yarn-cache action still open here).

Build Core Debug once per PR and share the artifact with the spec/parity jobs.
Path-gate Frontend Smoke, CLI Parity and Board Parity so backend-only or docs-only PRs skip them.
A "ready-to-merge" lane: run the full matrix once on the merge candidate rather than on every push of every branch.
Pin runner images used by Backend Specs so proxy generation (12–15 min on 10-17) is cached.

Acceptance.

A backend-only PR runs Backend Specs + policy only; a frontend-only PR skips Backend Specs.
Core Debug build appears once per PR run set.
Duplicate (workflow, SHA) runs for the same push are zero.
PR wall time p50 for Backend Specs ≤ 20 min on a normal day, measured over one week.

Item 7 (Chronicle Health) is out of date: the scheduled check now gets past tool installation, and its recent failures (28 of the last 30 runs) are real observer failures in Studio, not tooling. Those are tracked and being fixed in #1222. Lowering the frequency is still open here.

Proposal from Cratis/Workflows#205 (skip scheduled code-validation runs when the same workflow already succeeded on the same commit). No Studio change is made without your go-ahead.

The shared composite action is merged: skip-if-already-ran (Cratis/Workflows#206). A scheduled run skips when the same workflow already has a successful scheduled run on the same commit. Failed or cancelled runs rerun, workflow_dispatch and re-runs always run, and API errors run (fail open).

Proposed adoption in Studio:

integration-specs.yml: add the step to the existing detect job, which already runs on vars.RUNNER_GATE || 'cratis-arc-small' with actions: read, so no hosted job is started. Expose skip as a job output, and add needs.detect.outputs.skip != 'true' to specs (and to any other job, including always() jobs).
Out of scope, because they depend on inputs outside the commit: cli-parity (latest CLI release), align-versions (latest releases), the health checks and the cache warmers.
Known gap: a change to vars.PRODUCTION_CHRONICLE_KERNEL_VERSION without a commit is not part of the key; dispatch the workflow manually after changing it.

Reply here if you want it, and I'll send the change.

Direction

Option A. Studio takes ownership of the shared cache and makes the low-risk measurement and duplicate-work reductions first. It adopts the scheduled-code validation guard (Cratis/Workflows#205) for code-only schedules; monitoring schedules stay excluded. Deploy/publish shortcuts, audit-cadence changes and resource reductions each need separate owner approval and acceptance criteria.

Why: the shared guard already exists, and these steps cut CI time without touching the deploy, audit or resource policies.

Reversible; the owner may override.

@woksin

Two of the proposals here shipped in https://github.com/Cratis/Studio/pull/2498 (Studio v0.313.0). The frontend workflows now use the shared Cratis/Workflows yarn-cache action, which caches only Yarn's cache folder and never node_modules. Scheduled integration runs also skip a commit that already passed. The rest of this issue stays with @woksin, as handed over.

Closing. Every proposal here that fits the agreed direction (low-risk measurement and duplicate-work reductions) has shipped, has been superseded, or is no longer needed. The three proposals that need owner approval have moved to #1278.

Compile Core once per push: Frontend Smoke reuses the Backend Specs build output and now finishes in about 3 minutes (the target was 18 → 8). CLI Parity's trigger paths are narrow, and a pull-request run takes about 2 minutes (the target was under 5). Reusing the build there would make the run slower, because it would have to wait for Backend Build, so it is not done.
Split the Core spec lane: Core specs run as 4 parallel shards (Cratis/Studio#2510). The remaining timing work stays in Backend Specs: the Debug build and the Core spec lane set every pull request's wall time #1138.
One yarn cache: shipped in v0.313.0 (Cratis/Studio#2498), with the scheduled-run skip guard.
Gate checks on push to main: superseded. Backend Specs runs on main deliberately, so that every merge gets a result (Run Backend Specs on pushes to main so a red main is visible #1255). The other push checks are light and take about 30 seconds.
Container diagnostics: no longer needed, because Containers are removed on the shared CI Docker host while specs use them #905 was resolved without them.
Chronicle Health tooling: fixed. Its failures are real and tracked in Chronicle health check fails: persistent observer failures in Studio #1222. The frequency change is in Studio CI: three proposals that need owner approval (Publish bake, audit cadence, Chronicle Health frequency) #1278.
Backend Specs timeout: job timeouts are now 30–35 minutes, below the proposed 50.
Merging the six Frontend Build workflows: not done. It would save about 15 runner-minutes a week, rename the checks, and need skip conditions on gate jobs.
Publish bake and Dependency Audit cadence: moved to Studio CI: three proposals that need owner approval (Publish bake, audit cadence, Chronicle Health frequency) #1278.

Navigation Menu

Repository navigation

Make Studio's pull-request CI faster: proposals for review #906

Status

Direction

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Make Studio's pull-request CI faster: proposals for review #906

Description

Status

Activity

woksin commented on Oct 18, 2026

woksin commented on Oct 18, 2026

woksin commented on Oct 19, 2026

woksin commented on Oct 19, 2026

woksin commented on Oct 21, 2026

woksin commented on Oct 22, 2026

woksin commented on Oct 24, 2026

woksin commented on Oct 25, 2026

woksin commented on Oct 29, 2026

Direction

woksin commented on Oct 30, 2026

woksin commented on Nov 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions