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

Aberta
  • Algo errado?
#1,983 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
35/100
Tipo de issue
Refatoração
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
rust
Domínio
testing

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.
Linguagem predominante
Rust
Estrelas
9
Forks
2
Merge médio
18h 47min
PRs com merge (30d)
637

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de SocketDev/socket-patch

Todas as issues de SocketDev/socket-patch

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.