check-scope flags PRs that follow the CONTRIBUTING checklist (code + tests + changeset)
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 432
- Forks
- 51
- PR merge metrics
- No merged PRs in 30d
Description
Summary
The check-scope job flags PRs that follow the CONTRIBUTING checklist. A PR that ships code with tests and a changeset (both required for user-visible changes) always counts as 3+ areas and fails the check. Observed on #594, which contains only the mandated trio: two source files, their two test files, and one changeset.
There are two layers to this:
1. .changeset/* is misclassified as docs. In .github/scripts/classify-pr-files.sh, the chore patterns include .changeset/*, but the case statement evaluates in order and the docs pattern *.md comes first. Since changesets are all .md files, they always land in docs and the intended .changeset/* match is unreachable.
2. Even with that fixed, compliant PRs still trip the check. CONTRIBUTING requires code changes to ship with tests, and user-visible changes to ship with a changeset, so a compliant PR always touches code + test + changeset. That counts as 3 areas (code, test, chore) and fails. Splitting along those lines would produce a code PR with no tests, which the same guidelines forbid.
Proposal
Treat test files (*_test.go and the other test patterns) and .changeset/* as coupled to code rather than as separate areas, e.g. exclude them from the category count the way other already is, or only count them when no code files are present. The check would still catch genuinely mixed PRs (say, CI changes bundled with feature work) without flagging compliant ones. Reordering the case patterns so .changeset/* matches before *.md is worth doing regardless.
Acceptance criteria
- A PR containing only source files, their tests, and a changeset passes
check-scope. - Changeset files are classified as chore (or excluded), not docs.
- A PR mixing unrelated areas (e.g. workflows + source code + docs) still fails.
Happy to pick this up. Context: first noticed in https://github.com/dataiku/kiji-proxy/pull/594#issuecomment-4970559627.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in .github/scripts/classify-pr-files.sh, focusing on the case ordering for .md, .changeset/, and the test-file patterns. Trace how check-scope counts the resulting categories, then validate the acceptance criteria with a PR containing source files, their tests, and a changeset, while confirming unrelated workflows, source, and docs still fail.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, shell
- Domain
- ci-cd, tooling
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 74/100