Skip to content

ci: fail when the vendored core/ snapshots drift from upstream - #63

Open
srpatcha wants to merge 1 commit into
masterfrom
ci/guard-vendored-core-drift
Open

ci: fail when the vendored core/ snapshots drift from upstream#63
srpatcha wants to merge 1 commit into
masterfrom
ci/guard-vendored-core-drift

Conversation

@srpatcha

Copy link
Copy Markdown
Member

core/eos/ and core/eboot/ are copies of two other repositories in this organisation, not original source. Nothing keeps them in step, so fixes merged upstream never arrive here and nothing reports the gap.

Measured against origin/master of both repositories on 2026-08-28, by comparing git blob hashes:

Copy Files Still identical Already drifted
core/eos ← eos 350 306 44
core/eboot ← eBoot 167 120 46

Ninety files. Any security fix landed in eos or eBoot is absent from the copy here, silently — and the 21 pull requests currently open against eos will each widen the gap when they merge.

What lands

File
core/UPSTREAM.yaml the pinned upstream revisions
scripts/check_vendor_drift.py fetches each pin and compares
.github/workflows/vendor-drift.yml runs it on PRs touching core/, and weekly

The existing 90 files are grandfathered through baseline_drift so this can merge without blocking work in flight. New drift fails. Reducing drift lowers the baseline; raising the baseline to make CI pass defeats the file, and the script says so in its failure message.

This is a stopgap, not the fix

ADR-019 (embeddedos-org/eos#69) records the decision to replace both snapshots with real pinned dependencies, and to reconcile the 90 drifted files one at a time — each is either a change that belongs upstream, or one that should be reverted. Visible drift is not a fix; invisible drift is the actual danger.

Verification

The checker reproduces 44 and 46 independently of the git blob-hash comparison above. It exits 0 with the baselines set, and 1 when either is lowered. Workflow YAML parses; Python compiles clean.

core/eos/ and core/eboot/ are copies of two other repositories in this
organisation, not original source. Nothing keeps them in step, so fixes
merged upstream never arrive here and nothing reports the gap.

Measured against origin/master of both repositories on 2026-08-28:

    core/eos    350 files copied from eos     44 already drifted
    core/eboot  167 files copied from eBoot   46 already drifted

Ninety files. Any security fix landed in eos or eBoot is absent from the
copy here, silently, and the 21 pull requests currently open against eos
will each widen the gap when they merge.

This adds:

  core/UPSTREAM.yaml            the pinned upstream revisions
  scripts/check_vendor_drift.py fetches each pin and compares
  .github/workflows/...         runs it on PRs touching core/, and weekly

The existing 90 files are grandfathered through baseline_drift so this
can merge without blocking work in flight. New drift fails. Reducing the
drift lowers the baseline; raising the baseline to make CI pass defeats
the file and the script says so.

This is a stopgap, not the fix. ADR-019 in the eos repository records the
decision to replace both snapshots with real pinned dependencies, and to
reconcile the 90 drifted files one at a time — each is either a change
that belongs upstream, or one that should be reverted.

Verified: the checker reproduces 44 and 46 independently of the git
blob-hash comparison above, and exits 0 with the baselines set and 1 when
either is lowered.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant