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

Đang mở
#1,983 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
35/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
rust
Lĩnh vực
testing

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
Rust
Star
9
Fork
2
Merge trung bình
18 giờ 47 phút
Pull request đã merge (30 ngày)
637

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của SocketDev/socket-patch

Tất cả issue của SocketDev/socket-patch

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.