hermetic test children inherit GOFLAGS, GOENV, GOWORK, GOPATH and GOMODCACHE, which the go crawler and apply read; two hosted-production Go/Deno tests can't fail

Abierto
  • ¿Algo no está bien?
#1,981 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
55/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
deno, go, rust
Área
testing

Línea de trabajo

Start in crates/socket-patch-cli/tests/common/hermetic.rs, where the Extra enum and CRAWLER_EXTRAS live, and add a Go variant that scrubs GOFLAGS, GOWORK, GOPATH and GOMODCACHE and sets GOENV=off. Then replace the process-wide set_var calls in e2e_golang_build.rs and e2e_golang_hosted_build.rs with per-Command .env(..). Done means the four Go suites pass with GOFLAGS=-modfile=/nonexistent exported in the parent shell, and the two hosted-production tests in e2e_hosted_production.rs can fail.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

agent:triaged arch-audit bug priority:p3

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

Kind: bug (test hermeticity). Register ID: T66.

Problem

The CLI reads Go settings from the environment and from the Go env file:

  • go_env reads the variable, else the GOENV file, else $XDG_CONFIG_HOME/go/env (L110-L116).
  • The go crawler resolves the cache through GOMODCACHE and GOPATH (go_crawler.rs L186-L189).``
  • Go apply and vex honor GOFLAGS=-modfile (#1799), and vendor reads GOWORK.

The test scrub has an Extra for each other crawler that reads the environment (Venv, Bundle, Composer, Pdm, Poetry), but none for Go. CRAWLER_EXTRAS is [Venv, Bundle, Composer]. Every socket-patch child therefore inherits the developer's or runner's Go environment.

Consequences found while auditing:

  • Two hosted-production tests can't fail. In e2e_hosted_production.rs:
    • golang_hosted_redirects_only_via_goproxy_override writes a go.mod with no require and no go.sum. The crawl therefore walks the ambient GOMODCACHE/$HOME/go, and on a clean runner only "scan exit 0" is asserted.
    • deno_hosted_is_unsupported installs nothing, so it gets 0 pins whether or not hosted Deno is supported.
  • Process-wide env set and never restored.
    • e2e_golang_build.rs sets GOTOOLCHAIN with std::env::set_var and never restores it (L198). The binary has no serial_test, so sibling tests read the environment in parallel while it is set.
    • e2e_golang_hosted_build.rs sets GOTOOLCHAIN, GOFLAGS=-mod=mod and GONOSUMDB=* the same way (L376-L378).````` Its later CLI children and in-process discovery see these values depending on test order.
  • Only GOMODCACHE is pinned. run_socket pins GOMODCACHE only, so an ambient GOFLAGS=-modfile=… or a user go/env file reaches apply/apply --check.
Proposed change
  1. Add Extra::Go to hermetic.rs:
    • remove GOFLAGS, GOWORK, GOPATH and GOMODCACHE;
    • set GOENV=off.
  2. Include Extra::Go in CRAWLER_EXTRAS. Tests that need a value set it after the scrub, as they already do.
  3. Replace the process-wide set_var calls with per-Command .env(..) on the go and CLI children. Failing that, use a restoring guard under #[serial].
  4. In e2e_hosted_production.rs:
    • Give the golang leg a require + go.sum and a fixture GOMODCACHE, and assert the pin or skip code.
    • Install a Deno tree and assert a hosted_skips code, or delete the test.
Size

3–4 test files. About +40/−30 lines.

Acceptance criteria
  • With GOFLAGS=-modfile=/nonexistent and GOMODCACHE=/tmp/x exported in the parent shell, these suites still pass: e2e_golang, e2e_golang_build, e2e_golang_hosted_build and e2e_vendor_golang_build.
  • A hermetic selftest shows that the Go variables don't reach the child.
  • The two production tests fail when their claimed behavior is broken.
Lenguaje dominante
Rust
Estrellas
9
Forks
2
Merge medio
20 h 47 min
PR fusionados (30 d)
681

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de SocketDev/socket-patch

Todos los issues de SocketDev/socket-patch

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.