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

Offen
  • Stimmt etwas nicht?
#284 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
github-actions, python, shell
Bereich
ci-cd

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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

Vorherrschende Sprache
Python
Sterne
4
Forks
1
Ø Merge
10 Std. 41 Min.
Gemergte PRs (30 T.)
79

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus cpp-best-practices/project_validator

Alle Issues in cpp-best-practices/project_validator

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.