fix: refresh vendored data-connect tarballs and cross-repo pin - #39
Merged
Conversation
Rebuilds packages/polyfill-connectors/vendor/pdpp-collector-runtime-0.0.1.tgz from data-connect @ 9155e57ae47ab145214eb10551ed2c2185d7098a (data-connect PR #30: port of pdpp's dropped preservation-fixes-0819 hunks -- bare-specifier package validation, iMessage fixture date fix, connector-spawn tsx-resolution hardening). Only collector-runtime's contents changed; connector-protocol's tarball is byte-identical to what was already vendored, so its digest and package-lock.json entry are unchanged. vendor/pdpp-collector-runtime-0.0.1.tgz digest: old: 34443a3576f16c48049922fe53438e890cdfbbde67c0725a3a7fdca17ded042e new: e78fecd8c4ef74860cbeb3eb356b6c738e396f8d00fee21d5fdb8269604215e5 packages/polyfill-connectors/package-lock.json's resolution integrity for @pdpp/collector-runtime updated to match (sha512-90OO8/HPXf... -> sha512-r8wGrqsjE2fpw...). .github/cross-repo-pins.json's data-connect entry moves from the prior 9ef24d46 pin (PR #29, consumer-pin-required activation) to this new head. pdpp's pin is unchanged: my earlier pdpp vendor-refresh (pdpp PR #171) only touched vendor/pdpp-collector-runtime-0.0.1.tgz there, not packages/reference-contract, which is the only thing pdpp's pin backs here (drift job d, the reference-contract stand-in comparison). Also corrected packages/polyfill-connectors/vendor/README.md's pinned-commit references, which had drifted stale (documented 177adedcf..., but .github/cross-repo-pins.json actually recorded 9ef24d46... before this change) -- pre-existing drift, not introduced here, fixed while already touching this file. Content-manifest verified (not just raw tarball digest, matching check-tarball-digest-drift.sh's own methodology): extracted the committed tarball and a fresh `npm run build && npm pack` from a clean checkout of data-connect @ 9155e57, and diffed the per-file sha256 manifests of both -- identical. Verified: `npm ci` in packages/polyfill-connectors passes clean against the refreshed lockfile + tarball; full `npm test` run (839+ assertions across the suite) shows 0 failures. `npm run typecheck` could not be verified in this sandbox (tsc unavailable -- reproduces identically on unmodified main, a pre-existing environment gap unrelated to this change, not a regression). Assisted-by: AI Signed-off-by: Tim Nunamaker <tnunamak@gmail.com>
Schema Health Check — All ClearAll 63 scopes have consistent local schema files. |
The prior commit moved data-connect's pin but left pdpp's pin at a0924e9a4338550f945bd50a02fa1cf0cd4e8cec, which predates pdpp PR #171 (the vendor/pdpp-collector-runtime-0.0.1.tgz refresh needed to match data-connect's new pin). Drift job (c) (vendored tarball digests) checks BOTH this repo's and pdpp's vendor/SHA256SUMS against a fresh repack from the data-connect pin, so pdpp's tarball at the old pin failed that comparison: CI caught this (data-connectors PR #39, "Drift — vendored tarball digests" red) exactly as the pin-freshness mechanism is meant to. Moves the pdpp pin to 5eacd82e2f9822b555bda869429b842be66b1ff7 (merge commit of pdpp PR #171). packages/reference-contract and reference-implementation/runtime/recovery-reason-codes.ts -- the only files this pin otherwise backs (drift job d, the reference-contract stand-in comparison) -- are byte-identical between the old and new pin (confirmed via `git diff --stat <old> <new> -- <paths>`, empty). Verified: extracted pdpp's vendor/pdpp-collector-runtime-0.0.1.tgz and vendor/pdpp-connector-protocol-0.0.1.tgz at the new pin and diffed their per-file sha256 manifests against a fresh `npm run build && npm pack` from data-connect @ the pin in the same file -- both identical. Assisted-by: AI Signed-off-by: Tim Nunamaker <tnunamak@gmail.com>
Contributor
Author
|
Pushed a follow-up commit: the first commit moved data-connect's pin but left pdpp's pin stale, which is what made "Drift — vendored tarball digests" go red — the drift check compares both this repo's AND pdpp's vendor/SHA256SUMS against a fresh repack from the data-connect pin, and pdpp's vendored tarball at its old pin predates pdpp#171 (my earlier vendor refresh there). Moved pdpp's pin to that PR's merge commit; content-manifest-verified locally before pushing. |
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
1 participant
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.
Summary
Rebuilds
packages/polyfill-connectors/vendor/pdpp-collector-runtime-0.0.1.tgzfromPDP-Connect/data-connect @ 9155e57ae47ab145214eb10551ed2c2185d7098a(data-connect#30: port of pdpp's droppedpreservation-fixes-0819hunks — bare-specifier package validation, iMessage fixture date fix, connector-spawn tsx-resolution hardening).Only
collector-runtime's contents changed;connector-protocol's tarball is byte-identical to what was already vendored, so its digest andpackage-lock.jsonentry are unchanged.Digests:
vendor/pdpp-collector-runtime-0.0.1.tgz:34443a3576f16c48049922fe53438e890cdfbbde67c0725a3a7fdca17ded042e→e78fecd8c4ef74860cbeb3eb356b6c738e396f8d00fee21d5fdb8269604215e5vendor/pdpp-connector-protocol-0.0.1.tgz: unchangedpackages/polyfill-connectors/package-lock.json's resolution integrity for@pdpp/collector-runtimeupdated to match..github/cross-repo-pins.json'sdata-connectentry moves from the prior9ef24d46pin (PR #29) to this new head.pdpp's pin is unchanged — my earlier pdpp#171 vendor refresh only touchedvendor/pdpp-collector-runtime-0.0.1.tgzthere, notpackages/reference-contract, which is the only thing pdpp's pin here backs (drift job d, the reference-contract stand-in comparison).Also fixed:
packages/polyfill-connectors/vendor/README.md's pinned-commit references had drifted stale (documented177adedcf..., but.github/cross-repo-pins.jsonactually recorded9ef24d46...before this change) — pre-existing drift, not introduced here, corrected while already touching this file.Verification
check-tarball-digest-drift.sh's own methodology (not just raw tarball digest, which isn't byte-reproducible across npm versions): extracted the committed tarball and a freshnpm run build && npm packfrom a clean checkout of data-connect @9155e57, diffed the per-file sha256 manifests of both — identical.npm ciinpackages/polyfill-connectorspasses clean against the refreshed lockfile + tarball.npm testrun: 0 failures across the suite.npm run typecheckcould not be verified in my sandbox (tscunavailable — reproduces identically on unmodifiedmain, a pre-existing environment gap unrelated to this change, not a regression).Expected: this PR is the second half of the coordinated repin — the "Consumer drift signal" check on data-connect#30 went red before this merged (correctly, since data-connectors' pin hadn't caught up yet); it should go green once this is merged.
Assisted-by: AI