Skip to content

fix(ci): code-quality steps compare against a base commit absent from the shallow clone #13880

Closed

Description

@mrveiss

Discovered while reviewing PR #13877 (#13876). Pre-existing, unrelated to that PR.

Problem

.github/workflows/code-quality.yml checks out with actions/checkout@v7 and no fetch-depth, which defaults to 1. Several steps then diff against github.event.pull_request.base.sha, which is not present in a depth-1 clone. The diff fatals, the step reads the empty result as "no changed files", and reports success.

Live evidence from a recent run of this workflow:

code-quality  Block datetime.utcnow()...  fatal: bad object 69106af2e7c13e9ec88c7201265f5a50825b5ed5
code-quality  Block hardcoded value...    No changed source files — skipping pre-commit-hardcoded-values.

The job goes green having scanned nothing. Any regression these steps exist to block would pass today.

Scope

At least the changed-files-based steps in the code-quality job. Each needs auditing for whether it silently treats a failed diff as an empty diff.

PR #13877 works around this for its own step only — it fetches the single base object and hard-fails if the ref still will not resolve — deliberately not setting fetch-depth: 0, because reviving every dead sibling step at once would redden unrelated PRs with whatever pre-existing findings surface. That is this issue's job, done deliberately.

Implementation order

Wave 1 — enumerate every step in the job that diffs against a base ref, and determine which are currently no-ops (no blockers)
Wave 2 — set fetch-depth: 0 and fix whatever real findings surface (depends on wave 1)
Wave 3 — make a failed diff fatal in each step, so this cannot silently regress (depends on wave 2)

Acceptance criteria

  • Every base-diffing step in code-quality.yml resolves the base ref
  • A step whose diff command fails exits non-zero instead of reporting success
  • Findings surfaced by re-enabling the dead steps are fixed or tracked

Activity

  1. mrveiss commented on Aug 10, 2026

    @mrveiss
    OwnerAuthor

    Merged via #13883 as squash commit 857ac874d.

    Delivered — verified in Dev_new_gui

    $ git show origin/Dev_new_gui:pipeline-scripts/check-pre-commit-hook-pr.sh | grep -c EXT_PATHSPEC
    5      # pathspec is a quoted bash array; the shell no longer eats it
    $ git show origin/Dev_new_gui:.github/workflows/code-quality.yml | grep -c 'fetch-depth: 2'
    4
    

    CI proof the guards now execute, from the merged run:

    Checking 1 changed .py file(s) for banned patterns...
    Running pre-commit-hardcoded-values against 1 changed file(s)...
    Running tools/lint/check_no_hardcoded_ip_fallbacks.py against 1 changed file(s)...
    Running pre-commit-no-direct-redis against 1 changed file(s)...
    Running pre-commit-no-print-console against 1 changed file(s)...
    conventions scope: HEAD^1..HEAD (6 file(s))
    

    Every one of those previously printed No changed source files — skipping.

    Acceptance criteria

    Beyond the original scope

    The audit found a second, larger silent no-op: the extension pathspec was shell-expanded against the repo root, collapsing *.py onto ~5 root-level files. Four checks — hardcoded values (#694), hardcoded-IP (#6783), direct redis (#1086), print/console (#1082) — had therefore never enforced on backend Python.

    Also fixed: pipeline-scripts/ was in neither pytest.ini nor ci.yml, so 112 tests never ran, one of them red for as long as the bug it covered. And the no-print hook flagged print( inside string literals (e.g. an LLM prompt), which would have blocked PRs on documentation text.

  2. mrveiss commented on Aug 11, 2026

    @mrveiss
    OwnerAuthor

    Follow-up filed from this work: #13984 — the base-resolution logic corrected here is now duplicated across four files while scripts/lib/ exists as the canonical home.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions