Repository navigation
Run KSail managed CodeQL on a bounded platform ARC pool #4462
Description
🤖 Generated by the Agentic Engineer
Problem and evidence
KSail’s managed Go Code Quality analysis intermittently stops before producing results, blocking protected PR delivery. Its owned Linux collector completed all 14 extraction commands at ec15e8908331089c78fc33e97a7d51d51ef7b557; root and desktop commands peaked around 9.7 GB resident memory. Those are command measurements, not a total runner memory budget or an OOM diagnosis. The newer managed run at ff510a123255acd9f053b0faa78c6f370ecbd669 failed during autobuild without an explicit termination reason.
The maintainer has ruled out paid higher-memory GitHub-hosted runners and directed the self-hosted ARC path on platform infrastructure. No reusable current platform ARC deployment was established. Existing capacity must be verified rather than assumed, and organization runner policy is permission-unknown.
Proposed direction
Add a GitOps-managed ARC controller and a separate, repository-scoped KSail analysis pool, initially inactive. Use ephemeral nonprivileged runners, no host mounts or Docker socket, a unique label, zero idle runners and a maximum of one job runner. Deliver the approved App credential through the existing secret system without exposing it to job pods. Preserve platform network isolation and explicitly size the runner, listener and controller within the namespace policies.
Calibrate the actual managed Go and JavaScript workflow on this environment, including its proxy, tool installation and total pod memory. Activation depends on proven schedulable capacity and a bounded infrastructure plan; this issue does not authorize new billable capacity or broaden a shared credential. Do not restore the historical unrelated registration.
Acceptance criteria
- Commit pinned controller/pool manifests and an activation/recovery runbook; validate local and production renders and applicable policy/schema checks.
- Keep the new pool inactive until registration, isolation and capacity are verified; activation is a separate reversible step.
- Verify an approved KSail-scoped App registration and secret delivery without mounting the App secret in runner pods.
- Prove that the full runner/listener reservation fits the chosen capacity and policies; report aggregate pod peak, extractor measurements and extraction duration.
- Exercise the actual managed Go and JavaScript analysis on an ephemeral runner with all first-party coverage/source guards retained, and confirm the runner pod is removed afterward.
- Route managed Code Quality through the verified repository-assigned label, confirm configuration readback, and meet KSail #7131’s five-consecutive-run criterion before declaring the reliability problem fixed.
Size
Medium. Registration and capacity are concrete prerequisites; static manifests alone do not deliver the runtime remedy.
Part of devantler-tech/ksail#7131
Activity
chore: agent-claim #4462 nonce=4532e19e79a988c55563628dfea52803
chore: agent-claim #4462 nonce=d9f9f83be4b948980ba65e774a32a234
chore: agent-claim #4462 nonce=febfba6771607cf81f24b6bcaf07a374
chore: agent-claim #4462 nonce=7d8204f1032dd19798d48ffd90ae9b9f
chore: agent-claim #4462 nonce=eb4ee37508f3dff9ab2c94e974add078
devantler commentedon Oct 6, 2026
Correction to the earlier authentication request: completing GitHub confirmation cannot recover an existing App private key. The private maintainer message has been corrected in place; no repeated confirmation is requested.
The existing production App already has the approved permission. ARC can renew its installation tokens without further human clicks once its matching signing key is provisioned securely. A bounded read-only search has not located that key in the available secret store or visible credential inventory. The unresolved activation prerequisite is one-time key provisioning, not recurring authentication approval. No credential substitution or new App is proposed. Disabled organization-runner preparation in #4533 can merge independently; live activation and acceptance remain gated on #4544. | asked slack 2026-10-06
devantler commentedon Oct 6, 2026
Runner-group capability preparation against Platform main
788e960618a0ca1eeb3f7eb45061b24cc9287e45: the dedicated proof should own.github/workflows/verify-arc-runner-group-capability.yamlandscripts/verify-arc-runner-group-capability/, leaving #4544 and #4582 untouched. No implementation branch or native probe has been started in this round.The existing identity verifier deliberately makes only identity reads and exposes no installation token. A capability workflow needs a reviewed adapter that retains that verifier’s authenticated transport, live/source identity binding, bounded responses, non-printing credential handling and token revocation. It must not substitute a different App or duplicate a second credential provisioning path. This interface is an integration prerequisite while #4582 owns the identity verifier.
The proposed protected-main workflow uses the existing production environment and deployment lock, refuses retries and arbitrary dispatch refs, and tests/builds before production access. Credential-free PR fixtures must exercise the actual command with synthetic HTTPS/API responses. Dispatch remains gated on deployed TLS and the existing App identity proof; offline tests cannot establish organization capability.
GitHub’s runner-group API exposes explicit repository selection, public-repository allowance and workflow restrictions. The bounded native proof should first read an existing exactly matching group without modifying it. Otherwise it may create an unmistakably owned disposable group with zero runners, precisely the KSail repository, public access enabled, workflow restriction enabled and the protected-main canary workflow as its sole allowed workflow. Complete readback must verify identity, repository membership, policy flags, the exact workflow set and zero runners. An ambiguous create response, changed ownership or nonzero runner membership must fail closed; cleanup may delete only the proven owned disposable group and must verify absence. An existing group is never deleted or repaired by the probe.
The canary workflow allowance does not establish managed-analysis eligibility. GitHub documents default-setup runner selection, but that alone does not prove the actual managed workflow satisfies this group’s restriction. Record and review its native workflow identity separately before any route change; do not loosen the group to all workflows or candidate-controlled refs to obtain a passing canary.
Capability remains UNKNOWN. There has been no group API operation, runner registration, routing change, credential change, permission expansion or capacity purchase. The Platform working directory remains clean.