An `echo X=… >> $GITHUB_ENV` inside a shell `if` branch is taken as unconditional, and later steps with `if: env.X != …` are dropped silently

Abierto
  • ¿Algo no está bien?
#284 0 comentarios 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
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
github-actions, python, shell
Área
ci-cd

Línea de trabajo

The bug is in project_validator/ci/github_actions.py: _exported (around lines 139-145) records every echo NAME=value >> $GITHUB_ENV without checking the shell if around it, and the step-skip check near lines 268-270 drops steps whose if: depends on that value. Start by reproducing with the small workflow described in the issue and run --facts on it. Done means a step whose if: depends on a conditionally exported variable is either evaluated correctly or recorded as unknown rather than silently skipped, with a test covering it.

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

Descripción

zigtools/zls: a step sets SKIP_DEPLOY=true in $GITHUB_ENV only inside an if branch; the validator records the assignment unconditionally, every later step guarded by if: env.SKIP_DEPLOY != 'true' is dropped with no ERROR, and the zig build release -Doptimize=ReleaseSafe build is never seen (hardening FAIL "no ReleaseSafe build", ci-build-types "missing Release"). A value set under a condition is unknown; a step whose if: depends on it should be read (or recorded as unknown), not dropped.

Evidence from the corpus audit

zigtools/zls / hardening (also ci-build-types)
  • kind: FALSE_NEGATIVE
  • actual: FAIL: release builds drop Zig's safety checks: no ReleaseSafe build (ci-build-types: "linux / master: missing
    ... Release")
  • expected: PASS: the release workflow builds with -Doptimize=ReleaseSafe.
  • evidence: .github/workflows/artifacts.yml:23: if: github.event_name == 'schedule' (the step that may export);
    :32: echo "SKIP_DEPLOY=true" >> $GITHUB_ENV (inside if [ -n "$(git tag --points-at HEAD)" ]; then);
    :61: if: env.SKIP_DEPLOY != 'true'; :64: zig build release -Drelease-minisign -Doptimize=ReleaseSafe --summary all.
    Validator: project_validator/ci/github_actions.py:139-145 (_exported takes every echo NAME=value >> $GITHUB_ENV
    in the script, ignoring the shell if it sits in and the step's own unknown if:); :259-261 merges it into
    known.env; :268-270 runs = self.runs(step.get("if"), known); if runs is False: return drops the step with no
    fact and no "not read". --facts confirms: artifacts.yml yields facts for steps[0..1] only; no ActionStep for
    mlugg/setup-zig, no Command for step 7.
  • repro: .github/workflows/r.yml: job with steps run: |\n if [ -n "$X" ]; then\n echo "SKIP=true" >> $GITHUB_ENV\n fi
    then - uses: mlugg/setup-zig@v2\n if: env.SKIP != 'true' then - run: zig build -Doptimize=ReleaseSafe\n if: env.SKIP != 'true';
    build.zig with addExecutable. Reproduced in
    <scratch>/audit/repro-hard-githubenv
    (FAIL; the same workflow without the export PASSes).
  • confidence: high

Found by the regression-corpus audit (235 real repositories, one or more per ecosystem profile; corpus and expected results in corpus/). Evidence is quoted from the audited checkouts at the commits pinned in corpus/projects.toml; <checkouts>/<owner>__<repo> is such a checkout.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt

Lenguaje dominante
Python
Estrellas
4
Forks
1
Merge medio
10 h 41 min
PR fusionados (30 d)
79

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 cpp-best-practices/project_validator

Todos los issues de cpp-best-practices/project_validator

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.