Skip to content

fix(ci): contract-slice prune gate can report success over a root it never examined #1444

Description

@kyle-sexton

The contract-slice prune gate (scripts/check-contract-slice-prune.sh, landed by #1429 for #1417)
is a required check. Three separate defects let it report success over a contract root it never
actually examined — each one silently, with a green checkmark.

These were raised as live P2 review threads on #1429 and were still unresolved when that PR merged.

1. The concern-file scalar is parsed by a local fork that truncates at an adjacent hash

resolve_contract_dir strips comments with sed 's/[[:space:]]*#.*$//'. A valid plain scalar
contract_dir: docs/a#b resolves to docs/a, so both workflow steps ignore every change under the
real docs/a#b root.

lib/parse-concern-value.sh is this repository's single source of truth for exactly this parse and
already distinguishes a comment-starting # from an adjacent # — the inline fork reintroduces
the bug that helper exists to fix.

2. The resolved root is matched raw against git's canonical diff paths

Git emits diff paths as canonical repo-relative names. contract_dir: ./docs/topics — or any value
carrying reducible segments such as docs/x/../topics — is a valid setting that matches nothing, so
every slice under the configured root passes unexamined. An absolute or repo-escaping value is not
rejected either.

3. slug_of returns the FIRST matching root, not the most specific one

The gate deliberately polices the union of the base root and the head root, and those roots can
NEST: a PR may relocate contract_dir beneath the base root. Migrating a grandfathered slice to
docs/topics/legacy/legacy while legacy is baselined, then adding docs/topics/legacy/newslug,
makes both workflow checks pass — the outer root matches first and names legacy as the slug for
every path inside the relocated root, so the exemption covers the brand-new slice too.

Expected

Each root the gate claims to police is actually matched, and an exemption is granted only by the
root that actually owns the path.

Related

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions