Skip to content

DO NOT MERGE - integration stack CI - #1

Draft
jdsika wants to merge 6 commits into
3.0from
integration/3.0
Draft

DO NOT MERGE - integration stack CI#1
jdsika wants to merge 6 commits into
3.0from
integration/3.0

Conversation

@jdsika

@jdsika jdsika commented Oct 23, 2026

Copy link
Copy Markdown

Do not merge this PR. It exists only to run CI continuously against the combined feature stack.

Why this PR exists

Individual feature/* PRs are each validated in isolation against integration/3.0. Nothing
validates all stacked features together — this draft PR does, by diffing integration/3.0
against the pure upstream mirror 3.0. Its checks are the release gate before tagging an
ascs/3.0-* snapshot for the internal submodule pin.

Why it must never be merged

Merging would push the fork-only scaffolding and the whole feature stack into 3.0, destroying the
verbatim upstream mirror that every mirror/<slug> upstream PR is cut from. 3.0 is protected
against force-pushes, deletions, and non-linear history, but the real guard is this note and the
permanent draft status.

Lifecycle

  • The branch is rebased onto 3.0 whenever the mirror advances; this PR is force-updated and its
    checks simply re-run.
  • Commits that upstream merges are dropped during that rebase.
  • Keep it in draft forever. Close and reopen only if the branch is recreated.

See .github/copilot-instructions.md and CONTRIBUTING.md for the full fork process.

@jdsika
jdsika force-pushed the integration/3.0 branch 3 times, most recently from ac9c8a7 to 1934668 Compare October 23, 2026 09:37
@jdsika jdsika mentioned this pull request Oct 23, 2026
Merged
@jdsika jdsika added the do-not-merge Never use the merge button; applied by fixup (3.3) or never merged at all label Oct 23, 2026
This was referenced Oct 23, 2026
Closed
Closed
@jdsika jdsika mentioned this pull request Oct 23, 2026
Draft
@jdsika
jdsika force-pushed the integration/3.0 branch 2 times, most recently from b3fcee3 to eddee28 Compare October 26, 2026 14:45
@jdsika
jdsika force-pushed the integration/3.0 branch 3 times, most recently from cef3a07 to 17e264a Compare November 11, 2026 18:42
@jdsika
chore(fork): define the ASCS-eV fork process
c509ccd 
ASCS-eV/PufferDrive is consumed as a git submodule internally while feeding
features back to Emerge-Lab/PufferDrive. This commit carries everything that
exists only in the fork, and is the single place fork-only content lives.

Branch model:
  3.0              verbatim, fast-forward-only mirror of upstream/3.0
  integration/3.0  default branch; this commit plus a linear stack of
                   single-commit features; what internal consumers pin
  feature/<slug>   one feature, exactly one commit
  mirror/<slug>    cherry-picked onto pure upstream/3.0 for upstream PRs

integration/3.0 is the default branch because GitHub reads the PR template,
the contributing guidelines, the agent instructions and scheduled workflows
only from the default branch, and none of those files may exist on 3.0
without destroying the mirror. A clone checks out the default branch, so the
copy of the instructions here is the process as far as every agent and every
submodule consumer is concerned; a rule that lives only in an open PR has no
effect.

Nothing reaches integration/3.0 until three gates pass:
  1. CI green on the final commit.
  2. Adversarial review by someone other than the author, with the findings
     written down -- including the probes that found nothing.
  3. Upstream-readiness proven rather than asserted: the commit cherry-picks
     onto a branch cut from pure upstream/3.0 and produces an upstream-clean
     diff. We stack only commits we could contribute today.

chore(fork): commits are exempt from gate 3, since fork-only infrastructure
can never be upstream-ready. They carry two orthogonal markers: do-not-mirror
(must never reach upstream) and do-not-merge (the merge button is never
pressed -- merging would create a second chore(fork): commit and break the
single-commit invariant that every sync asserts). Such a PR is folded into
this commit by fixup and closed unmerged.

Contents:
- .github/copilot-instructions.md: normative process for coding agents
- CONTRIBUTING.md: human orientation, same rules
- .github/pull_request_template.md: testing and stack-hygiene gates
- .github/workflows/sync-mirror.yml: fast-forward-only mirror sync that
  refuses any non-fast-forward instead of rewriting the upstream base
- AGENTS.md / CLAUDE.md: fenced pointer so agents find the fork process
  without colliding with upstream-owned content
- ci.yml / install.yml: run CI for PRs targeting integration/3.0, which
  upstream's branch filters would otherwise skip

A standing draft PR from integration/3.0 into 3.0 gives a continuous CI
verdict on the combined stack; it must never be merged.

Everything here is fork-only and must never be cherry-picked upstream.
@jdsika
fix(ci): install CPU-only torch wheels in GitHub Actions
3e3ea86 
The Linux CI jobs fail while installing the package:

    [Errno 122] Disk quota exceeded

Errno 122 is EDQUOT, hit while unpacking the CUDA torch stack that
`pip install -e .` resolves by default. torch alone is 554.6 MB and the
accompanying nvidia-* wheels add another ~2.4 GB, which no longer fits
the runner's quota. The failure occurs during "Installing build
dependencies", i.e. the isolated PEP 517 build environment is already
enough to exceed it on its own.

The trigger is a runner image change, not a code change:

  * upstream 11_bernhard_dev, 2026-10-20, Image: ubuntu-24.04 -> success
  * same workflows, 2026-10-23, Image: ubuntu-26.04 -> failure

Both resolve an identical wheel set (torch 2.14.1, 554.6 MB). The
`ubuntu-latest` label began migrating to Ubuntu 26 on 2026-10-19
(actions/runner-images#14748), between those two runs. Both workflows
already carry "Free up disk space" steps, so these jobs were running
close to the limit before the migration.

Fix: install CPU-only torch from download.pytorch.org, then build with
--no-build-isolation so the build reuses it instead of resolving torch
a second time. --no-build-isolation needs the build dependencies present
up front, hence the explicit setuptools/wheel/numpy install; the
`setuptools<81` bound matches the pin already in install_requires.

This loses no coverage: BUILD_CUDA_EXT keys off CUDA_HOME/ROCM_HOME,
which is unset on these runners, so the CUDA sources were never compiled
here. tests/smoke_tests/Dockerfile already installs torch this way.

macOS keeps the plain `pip install -e .` unchanged: its PyPI wheels are
already CPU-only, and leaving it alone keeps the default PEP 517
build-isolation path under test somewhere in the matrix.
@jdsika
fix(ci): skip the fused encoder where triton is absent
1bd543f 
The shipped puffer_drive.yaml sets policy.fused_slot_encoder=true, and
DriveBackbone raises ImportError when that is set without triton. Two CI
jobs build a policy straight from the shipped config, so Unit Tests and
Notebook Execution have been failing on every pull request:

  ImportError: fused_slot_encoder=true requires triton

The smoke and eval suites already pin the flag off for exactly this reason;
these two call sites were simply missed. test_action_selection only exercises
the discrete-to-continuous action table, which the fused kernel has no part
in, so it pins the flag off outright. The inference notebook keeps the kernel
whenever it has a CUDA device and drops it otherwise, which is also what a
reader running the notebook on a laptop needs.

Neither change touches the training path or the kernel itself: with triton
and a GPU present, both call sites behave exactly as before.
@jdsika
docs: align the comment standard across AGENTS.md and CLAUDE.md
74a648b 
The two instruction files are byte-identical except for one line, and that line is a contradiction rather than a Claude-specific tweak. AGENTS.md asked for comments that explain invariants; CLAUDE.md banned them by default with a hard one-line cap and an explicit list of banned forms.

Agents load one file or the other depending on the tool, so the same codebase was being written to two different standards, and neither copy said the other existed. This adopts the stricter rule in both, because it is the one written for this codebase and the one the recent code follows.
@jdsika
fix(eval): resolve carla_cosim benchmarks and lint for unresolved names
bc1cf93 
Selecting the shipped carla_cosim benchmark crashed with UnboundLocalError:
the cosim branch of load_benchmark_config appended to resolved_benchmarks,
which is not assigned until after the loop it sits in. The parsed cosim
entries now accumulate in their own list and are appended to the normalized
replay benchmarks, so a selection may mix both kinds.

The bug is the kind a linter finds for free, so the ruff hook that has been
commented out since it was added is enabled, scoped to exactly that class of
defect: names that do not resolve and imports that are never used. The repo
has 104 other violations under ruff's full default set, most of them E402
import placement, and fixing those is neither this change nor obviously
desirable; a deliberately narrow select keeps the hook green today and lets
the set widen later alongside the fixes a wider set would demand.

Enabling it removed eight genuinely unused imports and required noqa markers
on the four import-availability probes that exist precisely to be unused.
tests/unit_tests/test_terminate_on_goal.py called pytest.main without
importing pytest, so its __main__ entry point had never worked.
@jdsika
ci: skip the test jobs on documentation-only pull requests
351531d 
A README or docstring change currently runs the full matrix -- unit, C, notebooks, a 30-minute Docker smoke train and the perf run -- none of which can observe a Markdown edit. On a fork whose process documentation changes often this is the single largest source of runner time, and it is pure waste.

A changes job diffs the PR against the merge base and votes code=false only when every changed path is recognised documentation (*.md, docs/, .github/ISSUE_TEMPLATE/). Anything unrecognised, and every push build, votes 	rue, so the failure direction is always 'run the tests'. The five heavy jobs gain
eeds: changes and an if:.

Job-level if: rather than workflow-level paths-ignore is deliberate: a workflow skipped by path filtering leaves its required checks pending forever and blocks the merge, whereas a skipped job is reported to branch protection as passing. No third-party action is used; the detection is five lines of git.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

do-not-merge Never use the merge button; applied by fixup (3.3) or never merged at all

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@jdsika