e2e_hosted_production and e2e_vendored_production are a near-fork: 11 identical helpers, a copied PURL/UUID catalog and hand-rolled VEX checkers beside vex_e2e_common

Aperta
  • Qualcosa non va?
#1,983 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
testing

Direzione di ricerca

Start by diffing the duplicated helpers (pm_command, published_uuids, urlencode, site_packages, assert_pristine/assert_patched) between crates/socket-patch-cli/tests/e2e_hosted_production.rs and e2e_vendored_production.rs, and compare them with tests/vex_e2e_common/mod.rs. Done means both suites still compile with cargo test --no-run and the hosted and vendored production CI legs run and skip the same set under the *_STRICT=1 variants. The drifted helpers need a maintainer decision on which variant to keep before you change them.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

agent:triaged arch-audit priority:p3 refactor

[agent] Filed by the scheduled architecture audit (audit-cli-tests). Register: register.

Kind: refactor. Register ID: T68.

Problem

The two #[ignore]d production suites (2,718 and 2,711 lines) share most of their harness by copy.

Identical copies (md5). 11 helpers are identical in e2e_hosted_production.rs and e2e_vendored_production.rs:

Helper Hosted Vendored
pm_command L447 L513
published_uuids L559 L687
urlencode L752 L716
minimist_entry L1003 L639
berry_skip_code L1585 L1470
site_packages L1833 L644
urllib3_patched L1852 L663
pypi_manifestless_vex L1874 L1793

The other three identical helpers are ok, dump and read. The PURL/UUID catalog is also copied, including all 6 gem UUIDs.

Drifted copies. 8 more have drifted:

  • strict and has_command;
  • tool, assert_pristine and assert_patched;
  • yarn_berry_vex, bun_manifestless_vex_production (38 lines differ) and gem_manifestless_vex (40 lines differ).

UNPUBLISHED_ECOSYSTEMS has drifted too: hosted probes 16 purls, vendored fewer.

Helpers rewritten inside the same binary. These shared helpers are already compiled into the hosted suite, which rewrites them anyway:

  • hosted_pin_count L421 duplicates common::envelope::hosted_pins(..).len().
  • urlencode duplicates vlt_e2e_common::urlencode.
  • site_packages duplicates uv_vex::site_packages.
  • berry_skip_code and the bun skip closure duplicate vex_e2e_common::skipped_reason.
  • The redirect-state.json absence check is hand-written 6× (L343, L1288, L1617, L1794, L2410, L2685) beside vex_e2e_common::assert_no_hosted_ledger.
  • 4 attestation checkers (pnpm L1274, berry L1551, bun L1766, gem L2385) duplicate assert_attested.
  • 2 VEX runners duplicate run_vex. Only the bun runner sets SOCKET_NO_API_TOKEN, so the copies have drifted.

Same-file duplication. GET + status + JSON parse is written 5× (L351, L559, L589, L626, L663).

Proposed change
  1. Add a tests/production_common/mod.rs holding:
    • the catalog (PURLs, UUIDs, UNPUBLISHED_ECOSYSTEMS as one list with per-mode filters);
    • one get_json(url) probe;
    • pm_command/tool/strict;
    • assert_pristine/assert_patched (drop the marker parameter: it is always PATCH_MARKER).
  2. Include it from both suites and delete the local copies.
  3. Replace the hand-rolled VEX runners and checkers, ledger checks and pin counts with the vex_e2e_common/envelope helpers already in the binary.
  4. The strict env-var names stay per suite, as a parameter.
Size

2 suites plus 1 new module. Roughly −600 lines.

Acceptance criteria
  • Both suites still compile (--no-run).
  • The CI "hosted production" and "vendored production" jobs pass under *_STRICT=1 with the same set of legs run and skipped. Compare the leg logs before and after.
  • The drifted helpers settle on the stricter variant, which the PR names.
Lingua principale
Rust
Stelle
9
Fork
2
Merge medio
20h 47m
PR unite (30g)
681

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di SocketDev/socket-patch

Tutte le issue di SocketDev/socket-patch

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.