Repository navigation
ci: dispatch-only post-runner capability canary (fleet-post-capability.yml) - #520
Merged
Merged
Conversation
…ility.yml)
New post VMs (pf-gcp-post-4/5/6) must pass this canary before laneboss
promotes them into the pf-gcp-post pool. workflow_dispatch only (no push,
pull_request or schedule trigger), permissions: {}, runs only on the
holding label pf-gcp-vm-<vm>; it builds nothing and runs no engine suite.
File installed verbatim from laneboss evidence (sha256 2e0e3e6b6497bc9f...).
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
The engine preflight pins every post-reachable job to [self-hosted, pf-gcp-post]. The new VMs keep that label but sit in the holding runner group pf-gcp-post-hold, whose restricted_to_workflows is exactly this file on main, so real post jobs cannot reach them before the canary passes (laneboss read-back + idle-under-queue proof). The file's hostname and runner-name guards still pin the run to the chosen VM. Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
…canary workflow (#520) fleet-post-capability.yml adds a 19th GCP-routed workflow job. The full preflight (not the PR-CI preflight stage) failed in test_gcp_sites_reject_cross_class_routes: len(sites) 19 != 18, and the exact (workflow, job) pair comparison was stale by the same job. The canary is recorded in its own DISPATCH_ONLY_CANARY_JOB_IDS, not in FLEET_JOB_IDS: that table also drives test_gcp_sites_require_every_routed_job (a deleted job must yield "is missing job X"), a finding scripts/ci_preflight.py only produces for workflows with a pinned-job entry, which the canary deliberately does not have. The count becomes 19 and the pair comparison stays exact (FLEET minus LIGHT plus the canary pair). New test_gcp_sites_pin_canary_to_the_dispatch_fleet (green on the base by design, a preservation control): the canary's sites are exactly [('capability', 'post')], the finding text is the post rule's, and routing the job to the PR fleet yields that finding. Known gap: no control fails if the canary's job is deleted (the checker has no required-job entry for it). Not run on the author's machine; the lab preflight run is the evidence.
…al/state/pineforge-top-core/lanes/ci-lab/clone into fu-postcap4
luisleo526
added a commit
that referenced
this pull request
Oct 26, 2026
…#520, p2cx-rjfast label #522) Brings in the two commits main gained since the last merge: the dispatch-only fleet-post-capability workflow (#520) and the drop of the "fast" label from the pytest row (#522, tests/cr150.d/p2cx-rjfast.cmake). No conflict; none of the 38 files of this branch is touched by either commit. The head the lab verifies and the pull request opens from therefore contains current main. Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
luisleo526
added a commit
that referenced
this pull request
Oct 26, 2026
## What Adds the `## 1.8.0 — 2026-10-27` section (with migration notes) to `CHANGELOG.md`, above `## 1.7.0`. `CHANGELOG.md` is the only file changed (+131/-0). Documentation only: no `src/`, `include/`, `docker/`, `scripts/`, `tests/` or workflow file is touched. ## Why The engine release body is generated from git-log subjects only and carries no migration notes; the release notes users read are this file (and the GitHub release body edited from it after publish). The notes must be on main before the release dispatch. ## Content - Compatibility and migration: exact pairing with codegen 1.8.0, regenerate C++ and relink every strategy library, no public header change, the new codegen `color` input type, the changed harness file `docker/run_json.py`. - Faster `run_json` report handling (#517) with the measured table against 1.6.3 and 1.7.0 and the statement that the gap to 1.6.3 is not closed. - Scratch placement restated (#518); the unused storage building block (#515; its allocation-gate sites are unreviewed, no bound claimed); a known limit (memory with never-filled pending orders, "a fix is planned for a later release"). - CI and release process: every merged change since 1.7.0 not listed above (#505-#510, #513, #514, #516, #519, #520, #522, #469, #481, #504). Every line is taken from the merged commit body; none claims a behaviour change for a tests-only or CI-only change. Not in this commit (not on main at base `641349a`): the release gate, tmpwatch and the TvJO fix. Each gets one line from its merged PR body as a follow-up commit on this branch before this PR merges; this PR is meant to merge after those three. ## Checks - Route: docs-only, `lab verify --via ci-only` (no sweep). - Read as a committed diff by an independent reviewer: GO. All 18 engine commits `v1.7.0..641349a` have a bullet, none extra. - Numbers: the #517 timings and RSS are the measurements in the #517 body; the ratios in the text were recomputed (1.77/0.36 = 4.9, 8.26/1.35 = 6.1, 8.94/5.39 = 1.66; 4.61/0.36 = 12.8, 22.31/1.35 = 16.5, 22.99/5.39 = 4.27). - The heading date `2026-10-27` is the planned tag date and is corrected before the tag if the date moves. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds
.github/workflows/fleet-post-capability.yml, a dispatch-only canary that each new post-merge VM (pf-gcp-post-4/5/6, approved for the 1.8.0 cut and the 1.8.1 load) must pass before laneboss promotes it into thepf-gcp-postpool.Properties (read at the file)
on: workflow_dispatchonly; inputvm= choice of pf-gcp-post-4 / -5 / -6. No push, pull_request or schedule trigger, so merging it starts nothing.permissions: {}; concurrency per VM.runs-on: [self-hosted, pf-gcp-vm-<vm>](the holding label: it can only land on that new VM before promotion).sudo -n true; the post apt line (libeigen3-dev tzdata-legacy ccache);docker info; a python probe of /dev/shm (tmpfs) and /var/tmp (disk) with two negative controls, writable temp candidates seen by inotify, /proc/self/fd, a sealed 32 MiB memfd, no leaked descriptors.File installed verbatim from laneboss's evidence (sha256 prefix 2e0e3e6b6497bc9f). Files touched:
.github/workflows/fleet-post-capability.ymlonly. CI-only route; promotes no baseline.🤖 Generated with Claude Code