The App token cannot update a run the job token created and vice versa, so
selecting runs by `app.slug === 'github-actions'` missed every App run: each
phase created another run, a published App success was never revoked, and a
head with an older job-token run made the App patch fail. Select runs by the
publishing app slug instead, pass `vars.DSH_APPROVAL_APP_SLUG`, and set the
external_id marker on the setup-phase run too.
Cover the App-owned update and the job-run coexistence, and align the note with
the measured earliest-suite rule and the App slug variable.
The dedicated-App edit changed the note's decision section without re-recording
its translation sidecar, and the client-id replacement also hit the issue
lifecycle workflow assertion. Re-record the pair and restore the issue App's
variable names in that test.
* ci: run native Windows PR jobs in a separate workflow
GitHub re-runs failed jobs only after a whole run finishes, so slow Windows jobs blocked re-running failed Linux jobs. CI Windows now owns the native Windows jobs and the Windows x64 Python runtime target, with its own required 'windows checks passed' verdict.
Refs #6893
* ci: run Python PR jobs in a separate workflow
Python rarely fails while the Windows lanes run long, so the Python SDK suite and the Linux/Windows x64 runtime matrix move into CI Python. The three pull-request workflows can now be re-run without waiting for each other, and branch protection gains "python checks passed" beside the existing verdicts.
Refs #6893
* docs: record the three PR verdicts in the failover runbook
* test: pin the shared environment across the PR workflows
* test: read the python SDK lane from CI Python
* test(sdk): parse session JSONL frames in the keyless smoke
Node 24.19 returned only the first frame of a concatenated zstd log, so the single JSON.parse saw just the header; 24.22 returns every frame and the JSONL body broke the parse. Read frames explicitly and select the main session by its header so both versions agree.
Mint the check-run token from a dedicated approval App instead of a shared
automation App, so the identity that owns the decision check suite is specific to
this gate. The workflow reads `vars.DSH_APPROVAL_APP_CLIENT_ID` and
`secrets.DSH_APPROVAL_APP_PRIVATE_KEY`, and the token stays scoped to
`checks: write`.
The decision check run kept its job-token check suite out of the pull request's
merge box: GitHub associates check runs with a pull request through the check
suite of the workflow run, and a `pull_request_target` run is not associated.
Mint a token from the repository App scoped to `checks: write` and publish only
the check run with it, so the merge box lists the label; the commit status gate
keeps using the job token and is unaffected when the token or the write fails.
Pin the token step, its single secret reference, and the client split in the
workflow and approval tests, and record the measured association limit in the
Agent Note and review-ownership README.
Only add the `weighted approval decision` check run: the required
`weighted approval` commit status keeps its `pending`, `success`, and `error`
states exactly as before, and branch rules keep requiring it. The check run
reports the same decision as a conclusion label and is not required, so it
never blocks a merge.
The Agent Note and README now state the status semantics as unchanged and the
measured reason a required check run is not available here.
The required check run introduced previously is not matched by this repository's
branch rules, so the gate could not be satisfied. Keep the required
`weighted approval` commit status as the gate and publish the
`weighted approval decision` check run as the label: action_required while the
policy is unmet, success when it holds, failure on setup or evaluation errors.
The status completes as success or failure instead of waiting as pending, so CI
watchers end.
Record the measured check-run limit, the revocation and recorded-conclusion
design, and the alternatives in the Agent Note; update the review-ownership
README, the workflow permissions, and the approval tests.
The evaluation failure title was preserved by matching details_url, a field
GitHub may rewrite for check runs created with the workflow token, so the
setup-failure step could replace the specific title after all. Record the
conclusion the publish step wrote in a step output and run the setup-failure
step only when no conclusion was recorded; a published decision now survives
a later failure or cancellation without relying on an API field.
Record the measured timeout cancellation path and the re-run migration limit in
the decision note, and scope the pre-push guidance to ACTION_REQUIRED so a
failure conclusion is not read as an approval wait.
The Wine gate compiled the Host face with one `tsc -b tsconfig.host.json`,
which holds the project-reference graph and the aggregate program in a
single V8 process and aborted at 4063.4 of 4088.3 MB. The supported build
splits those steps, and the native Windows build in the same run compiled
the references at 4096 and reached the aggregate without running out of
memory.
Compile the referenced projects first, then type-check the aggregate, both
at 4096. Assert the two commands and their order, and reject the fused
invocation.
Co-authored-by: turtle1999 <[email protected]>
Type checks only need Host declarations and Typert-generated
declarations, but typecheck, lint, lint:fix, doc-typecheck, and the CI
typert-contracts gate rebuilt the whole Host tsdown pass, Desktop bundle
included, to obtain them. A source-only scripts/generate-typert.ts now
runs the same generator and artifact writer as the tsdown plugin, beside
Host package compilation: Typert reads only sources once the missing
@deepseek-ai/dsh-client-file-upload/types path alias exists, and
rejectBuildOutputs fails the pass when a workspace lib/ declaration
enters its program. typecheck runs as a build.ts scope that checks both
aggregates in build mode after their own face compiles.
Refs #5852
build:artifacts produces every artifact, including the tsdown bundles,
the Desktop bundle, and Web, so naming it after sources undersold it;
build:check checks scripts, benchmarks, and website code besides tests.
The build.ts scopes, aggregate step ids, the Python builder flag
(--build-artifacts), workflows, callers, docs, and the build-split Agent
Note follow the new names. The note also records the naming
alternatives.
Refs #5852
pnpm run build ran every step in one serial chain, including the two
noEmit aggregate programs (tests, scripts, benchmarks, website) that no
artifact step consumes, so the Host aggregate check alone delayed tsdown by
about 66 s.
- build:src (scripts/build.ts --scope src) builds every artifact in the
existing order and writes the client build record; it replaces the
removed --artifacts-only flag and the libraries CLI mode.
- build:test (--scope test) type-checks only the Host and Client aggregate
programs with tsc -p, concurrently, without compiling references or
checking prerequisites.
- build runs both as one dependency graph through run-gates' new
runAggregate: each aggregate check starts once its face's packages are
compiled, and Client compilation stays after the Host bundle that writes
the Typert /remote declarations. DSH_GATE_CONCURRENCY=1 serializes it;
DSH_GATE_FAIL_FAST=1 stops the remaining steps at the first failure.
Passing steps print one PASS line (DSH_GATE_VERBOSE=1 shows their output).
- PR artifact builds (e2e, release, preview, Node 22 compatibility) and the
Python builder (--build-src) use build:src; dev:web and dev:desktop use
build:src. test:*, bench, typecheck and the required consumer/Windows
lanes keep the complete build.
- lint, lint:fix, doc-typecheck and the Typert contracts gate prepare with
host-libraries (Host package compilation + Host bundle) instead of
build:lib:host; their own checks never read the aggregate root or the
Desktop bundle.
Parallel and serial build produce byte-identical lib/, Web dist and client
build record; a test-only type error fails build and build:test while
build:src passes.
Refs #5852
The upload warns instead of silently ignoring missing files, and the spec
pins the upload after the benchmark step. benchmarks/AGENTS.md and the
report Agent Note now name the artifact CI publishes.
Refs #5840
The node-24-bench job uploads benchmarks/.dsh-report after the benchmark
step, including when a budget assertion fails, so the report the Vitest
globalSetup renders survives the runner. #5838 deferred this step because
the authoring token had no workflow scope.
Refs #5838
pnpm 11.28.5 runs verifyDepsBeforeRun before a script, so `pnpm run install`
inside the installed node-pty directory first installed node-pty's own
dependencies into the package and ran its `prepare` build. Both reached the
packaged payload: the SEA blob then carried a node-gyp tree and tripled pkg's
file records, and postject aborted while injecting it. The step now runs the
package's install script alone, as it did with pnpm 11.7.0.
A check run that reached completed never returns to in_progress: GitHub
answers 200 and leaves the run completed, so the revoke write was a
silent no-op on every re-evaluation and a published success survived an
interrupted setup or history fetch. Revoke a published success by
concluding it action_required, start a head that has no decision in
progress, and drop the status-only check-run update.
The setup-failure step ran only when the revoke step succeeded, so a
failed or cancelled publisher left the earlier conclusion standing. It
now runs on failure and on a cancellation that precedes the decision.
The decision note, the review-ownership README, and the two related
notes record the measured transition matrix and the fallback condition.
Unmet weighted approval conditions previously left a pending commit
status that CI watchers treat as running work, so gh pr checks --watch
and similar monitors never finished. Publish the decision as the
weighted approval decision check run instead: action_required blocks
merging while completing the check, and failure reports evaluation
errors.
Resolves the semantic conflict with #5331: its ci-unit gate spread
coverageTestTimeoutArgs, which this branch retires; the gate is now a
plain vitest run and the darwin lane budget reaches vitest.config.ts
through the inherited DSH_COVERAGE_TEST_TIMEOUT_MS. The ci-unit spec
cases pin that shape under both budget values.
Keep each case at its hardest setting that fits five minutes of hosted CI:
search and fork stay at 1,000 Sessions with the longest fork sampled once,
the list runs 3 samples over 3,000 Sessions, and seeding validates authored
bodies in memory instead of a separate verification pass. The file's last
case asserts the limit; the benchmark job timeout becomes 20 minutes.
Standard two-CPU hosted runs are 2.4-3.4 times the reference machine, above
the shared reference scale, so the budgets use rounded hosted medians with
the shared 1.25 headroom. The benchmark job took 14.4 minutes with these
cases; its timeout becomes 25 minutes.
Add a required benchmark over synthetic corpora whose per-Session length
distribution is at least a measured local DSH corpus: list at 1,000 and
5,000 Sessions, cold and built content search and stratified forks at
1,000 Sessions, all through the real SessionController on built plain-Node
workers. Raise the benchmark job timeout to 30 minutes for the added cases.
The fixture's poll case counts attempts instead of reading a clock, so a host
stall cannot turn a budget-ended poll into a pass; the control case reads the
poll's reported duration, which the 1000 ms default bounds from below. The
spawning spec acquires its temporary config in beforeAll, bounds the child
with a timeout and asserts no signal ended it, and counts the polled values it
inspects. CoverageTestTimeoutOptions is Vitest's own TestUserConfig members;
the rule's reach has one home in its JSDoc, which the config, gate, spec, and
note comments reference.
DSH_COVERAGE_TEST_TIMEOUT_MS expanded to --testTimeout, --hookTimeout, and
--expect.poll.timeout on the coverage and serial lanes, but Vitest forwards
only a fixed list of CLI overrides into inline projects and neither
hookTimeout nor expect is on it, so under the root config's two projects the
hook and expect.poll budgets stayed at Vitest's defaults on every lane.
vitest.config.ts now reads the variable through coverageTestTimeoutOptions and
spreads the three budgets into both projects; run-gates and the partition
coordinator pass no timeout flags, leaving one owner for the rule. A new spec
spawns vitest on the root config with a 200 ms budget and proves all three
waits end inside both projects, that unset keeps the defaults, and that a
malformed value fails at config load.
Fixes#5335
Related to #5325
The unit-darwin job ran the whole unit inventory at Vitest's 5000 ms default
on a shared 3-vCPU macos-latest runner; the first two master runs after #5292
each timed out a different set of cases that pass in under a second on a quiet
host. Every other whole-inventory lane raises the budget through
DSH_COVERAGE_TEST_TIMEOUT_MS=90000.
The job now sets that variable and runs `pnpm run check:ci:unit`, a run-gates
aggregate that is `pnpm run test` (native build, then `vitest run`) through the
path that consumes it. ci-unit receives no CI worker settings, so the inventory
inherits the environment `pnpm run test` finds: on a 3-CPU host the defaults
would inject DSH_COVERAGE_PARTITIONS=2, which run-gates.spec.ts reads as a
partitioned coverage lane.
Fixes#5325
The merged dependency repair in #4589 uses a recorded Launchpad build,
but #4591 also requires a regression guard against restoring the live
Ubuntu package pool. Those pool URLs disappear when versions are
superseded, even when the content digest is pinned.
Adapt LegGasai's URL guard from closed PR #4590 to the build-specific
endpoint that landed in #4589. Check the endpoint structure without
copying the current build number, version, or checksum into the test,
and reject Ubuntu pool downloads anywhere in the script so adding a
pool fallback cannot bypass the guard.
Negative controls restore the original archive URL and inject security
and ports pool fallback URLs; each fails the new guard. The original
script is restored byte-for-byte before all 44 workflow tests pass.
This adds only a static regression test, with no network calls or
changes to the download script or CI execution behavior.
Co-authored-by: LegGasai <[email protected]>
* ci: trial smaller Blacksmith static and observational runners
* ci: measure the 16-vCPU control for runner sizing
* ci: use 4-vCPU static and 8-vCPU observational runners
* ci: retain 8-vCPU static runner for completion time
Chinesezjc