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

Ouverte
  • Quelque chose ne va pas ?
#1,983 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
35/100
Type d'issue
Refactorisation
Clarté
Plutôt claire
Activité
Active
Stack technique
rust
Domaine
testing

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
Rust
Étoiles
9
Forks
2
Merge moyen
18 h 47 min
PR mergées (30 j)
637

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de SocketDev/socket-patch

Toutes les issues de SocketDev/socket-patch

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.