Repository navigation
build: fail-closed staging for the SDK package build — portal preflight, verified staging copy, private PORTAL_DIR - #918
Conversation
|
Per repo policy this requires sign-off from @felixfelix-bot before merge — leaving open for review (same as #916). |
|
Fix pushed: the preflight's first live run (ai-legion, fully-staged tree) falsely reported 'stale' — it checked for |
Review: APPROVEReviewed cold at head What it does: the SDK package build gains a portal preflight ( 1. The unwritable-tree refusal works. Private It also checks 2. The preflight catches a missing bundle — and, importantly, a stale one. I drove
The stamp check is the part worth highlighting. The PR is described as catching "a missing or 3. Staging is namespaced.
Scope note (correct, not a gap): this preflights the inputs to the SDK build and refuses Not hardware-tested — a host-side build script. I verified the guard logic by exercising the Labels: not applied — this account has FULL_REVIEW: ~/reports/reviews/tollgate-module-basic-go-pr918-kimi.md |
05b8ae5 to
b876fbf
Compare
|
Rebased onto current main (was CONFLICTING in |
Local CI gate — PR #918: build: fail-closed staging for the SDK package build — portal preflight, verified staging copy, private PORTAL_DIRRun of
Verdict: 2 leg(s) RED — 4 green. What this gate does not run (no vacuous green)
failing-leg log tailscontract-fences — tailgo-battery — tail |
|
Evidence review: verified at head — the three preconditions each fail fast, named, and early (the session that hit all three is the receipt). The doc-facts module-count red at head is the known main-side #1000-class drift (stale base), not this PR. Ready post-rebase; human gate. |
c03rad0r
left a comment
There was a problem hiding this comment.
Technical review — approving content; branch needs a rebase.
All three preconditions were cheap to check and expensive to discover late: the portal products are gitignored build outputs, a truncated staging copy, and a shared /tmp portal tree that one user could leave unwritable for the next. Failing in seconds with the named remediation (make portal-build, private PORTAL_DIR, disk-full path) instead of ten minutes into the SDK container is the right trade.
The per-checkout .portal-tree default plus the explicit writability refusal is the correct fix for the shared-path class (the same one #948 fixed for logs). mktemp -d "${TMPDIR:-/tmp}/..." keeps the staging dir private and visible.
Rebase required (CONFLICTING after the recent main moves); no code concern beyond that.
Disposition: land after rebase.
Rebuilt on current main: keeps the #941 version knob and adds the portal preflight (rebuild from the pin or abort with the named remediation), the verified staging copy, and a private TMPDIR-backed staging dir. The portal working tree defaults to a per-checkout .portal-tree.
b876fbf to
f60514b
Compare
|
Post-merge verification record (recorded after merge). Rebuilt keeping the #941 version knob, adding the portal preflight (rebuild from the pin or abort with named remediation), the verified staging copy and a private TMPDIR-backed staging dir; Verified: A full SDK container build was not run (no SDK on the bench host); the preflight paths and their ordering were reviewed. |
What
The SDK package build had three unchecked preconditions that each failed
late, deep, and unnamed (all three hit in one session on two hosts):
five gitignored build products that only
make portal-buildproduces;building without them dies ~10 min inside the SDK container with
install: cannot stat … 999-tollgate-admin-setup. Nowbuild-sdk-package.shverifies every product plus the existingpackaging/portal-resolved.shastamp against the manifest pin beforeany work, and either rebuilds the bundle from the pinned tree itself
or (with
SKIP_PORTAL_BUILD=1) refuses naming the exact remediation.PORTAL_DIRdefaulted to a fixed shared/tmppath. On amulti-user host one user's
node_modulesEACCES'd the next user'sbuild, and untracked dependency state sat mutable between the pinned
checkout and
npm ci. Default is now a per-checkout<repo>/.portal-tree(gitignored); an unwritable tree is a namedrefusal, never an npm-internal permission error.
No rule to make target. Full/tmp or quota produced a partial
cp -rwhose only symptom appearedinside the SDK. The staging copy is now verified file-by-file before
docker run, and the scratch dir respectsTMPDIR.Verification
bash -non both scripts; refusal paths exercised live: missingproducts +
SKIP_PORTAL_BUILD=1→ instantrc=1withRun: make portal-build; default path auto-runs the portal build and the chainfails closed on the node pin (
node v26.8.2 != pinned v22.17.0) withthe pin error — every refusal names its fix.
pinned SHA, artifact produced) in the same session, before this fence
existed; the fence now fronts exactly that sequence.
No recipe/behavior change for a correctly-staged tree: preflight passes,
build proceeds unchanged.