Skip to content

release-plz PR job has been failing on main since #241 (tracked-and-ignored .pem fixtures) #273

Description

@rubenhensen

delivery.yml's Release-plz PR job has failed on every push to main since 2026-07-16. Twelve consecutive runs, most recently 30448113952.

ERROR failed to update packages
  1: the working directory of this project has uncommitted changes. If these files
     are both committed and in .gitignore, either delete them or remove them from
     .gitignore.
     ["pg-pkg/testdata/jwt_rotation/priv_a.pem", "pg-pkg/testdata/jwt_rotation/priv_b.pem",
      "pg-pkg/testdata/jwt_rotation/pub_a.pem", "pg-pkg/testdata/jwt_rotation/pub_b.pem"]

Cause

Root .gitignore line 15 is *.pem. #241 committed four JWT-rotation fixtures under pg-pkg/testdata/jwt_rotation/, so those files are tracked and ignored. release-plz refuses to run against a repo in that state.

git ls-files -ci --exclude-standard on a clean checkout of main lists all four. The first failing run is the merge commit of #241 itself, so the bisect needs no searching.

Why nobody noticed

Release-plz release is a separate job and is unaffected: it still tags and publishes, so releases kept working and the workflow's Docker jobs stayed green. Only the job that opens the version-bump PR is broken.

The consequence is on PR #187 (chore: release), which is still open and was last updated 2026-07-16. Every version bump and changelog entry for what has merged since that date is missing from it. That covers the wire-compat gate, COMPATIBILITY.md, cargo-semver-checks, the oasdiff gate and the quinn-proto bump, among others.

Fix

One line, negating the four fixtures out of *.pem:

!pg-pkg/testdata/jwt_rotation/*.pem

Verified locally: with that line, git ls-files -ci --exclude-standard is empty and release-plz update gets past the check and starts resolving versions.

The commit is already written as f3120b1 on spike/cryptify-in-workspace, where it was needed to get the #255 spike far enough to answer its release-plz question. It should land on its own rather than riding that branch.

Worth guarding

Nothing in CI reports this class. A git ls-files -ci --exclude-standard check that fails when the list is non-empty is a two-line step and would have caught it in #241's own PR, before it reached main. Same shape as the other gates in #247: cheap, executable, fails loud.

Found while working #255.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions