Skip to content

ci: fail the build when a file is both tracked and gitignored #275

Description

@rubenhensen

#273 took delivery.yml's Release-plz PR job down for two weeks and twelve runs. The cause was a file being both tracked and ignored: #241 committed four fixtures under pg-pkg/testdata/jwt_rotation/, and root .gitignore's *.pem matched them. release-plz refuses to run against a repo in that state.

#274 fixed the instance. Nothing stops the next one.

Why it went unnoticed for two weeks

Two things had to line up, and both will line up again:

  • The failing job is not the visible one. Release-plz release is a separate job and kept succeeding, so releases still tagged and the Docker jobs stayed green. Only the job that opens the version-bump PR was dead.
  • The damage is a PR that stops changing. chore: release #187 sat open and simply stopped updating. A frozen PR looks identical to a PR with nothing to add.

Neither is a monitoring gap that better dashboards would close. The condition is detectable in the repo itself, for free, at PR time.

The check

git ls-files -ci --exclude-standard

Lists every file that is tracked and matched by an ignore rule. On a healthy tree it prints nothing. Non-empty output is the bug.

Suggested step, failing loud with the list and the fix:

- name: No tracked-and-ignored files
  run: |
    conflicted=$(git ls-files -ci --exclude-standard)
    if [ -n "$conflicted" ]; then
      echo "::error::These files are tracked AND matched by .gitignore."
      echo "$conflicted"
      echo "release-plz refuses to run against this state (see #273)."
      echo "Fix: add a negation to .gitignore, or git rm --cached the files."
      exit 1
    fi

It needs the repo checked out and nothing else — no toolchain, no cache. It would have gone red on #241's own PR, before main ever saw it.

Notes for whoever picks this up

  • It belongs on a workflow that runs on every PR and always reports. build.yml already has jobs shaped that way, and the file's existing comments explain why a path-filtered job is the wrong shape for anything that might become required.
  • dobby-coder cannot push .github/workflows/* on this repo, so if an agent does the work it has to hand the YAML to a maintainer to paste. See CLAUDE.md.
  • Worth considering while in there: *.pem is a broad rule to have in a repo that legitimately commits test keypairs. Scoping it (or dropping it in favour of specific paths) would remove the trap rather than detect it. The guard is still wanted either way, because the same shape can recur with *.patch or any future blanket rule.

Follows #273 / #274. Part of the "fail closed, fail loud" line in #247.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions