ci: enforce the pending-changesets convention and align the docs - #282
Merged
Conversation
📦 Bundle size impactComparing No size changes detected. 🟢 |
TarikGul
reviewed
Aug 10, 2026
TarikGul
approved these changes
Aug 10, 2026
al3mart
added a commit
to Polkadot-Community-Foundation/product-sdk
that referenced
this pull request
Aug 14, 2026
Upstream's new changeset-location.yml (paritytech#282) runs on `parity-default`, a Parity-only runner that does not exist in this fork, so the job queues forever and leaves a permanently-pending check on every PR — it is deliberately unfiltered so it can be marked required. Same retargeting this fork already applies to the other CI workflows; the job is just checkout + a git-diff/awk script, so ubuntu-latest is fine.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Adds a CI check that fails a pull request when it puts a changeset file into
product-sdk/.changeset/instead ofproduct-sdk/pending-changesets/, whetherdirectly or inside a subdirectory.
The check allows the one case where a file legitimately arrives in
.changeset/:a release PR promoting a changeset that was already parked in
pending-changesets/.Changes
.github/workflows/changeset-location.yml(new file)A single job that checks out the repository and compares the pull request against
its base commit, using a three-dot diff so that adding a changeset and moving it in
a later commit ends up green. It collects two kinds of offender:
.mdadded directly underproduct-sdk/.changeset/,except
README.md.--no-renamesmakes a legitimate promotion appear as an addunder
.changeset/plus a delete of the same basename underpending-changesets/,and those cancel each other out. Whatever add is left over was authored straight
into
.changeset/. Deletes are matched at any depth, so promoting a changesetparked in a
pending-changesets/subdirectory still counts as a promotion..changeset/subdirectory, of any extension, never cancelledby a promotion delete. There is no legitimate promotion into a subdirectory.
Failures produce one inline annotation per file in the Files changed tab, plus a
copy-paste block of remediation commands, deduplicated so several files sharing one
offending directory print a single
git rm -r. Cause and fix differ by depth, so themessages do too:
git mvfor a direct file,git rm -rfor a directory.The workflow deliberately has no
paths:filter, unlike the other workflows in thisrepository. A path filtered workflow reports no status on pull requests that do not
match its filter, and a required check that never reports leaves the pull request
waiting forever. This one always runs, so it can safely be marked required in the
branch ruleset.
CLAUDE.md,product-sdk/RELEASES.md,product-sdk/pending-changesets/README.mdAll three said the pull request that closes the work promotes its own changeset. They
now say a separate
chore(release):pull request does it, name the CI check, and warnthat the filename must not change during the move. No behaviour change, these are the
instructions people follow.
Known limitation
A release pull request passes only if it purely promotes. Authoring a new changeset inside one fails and needs a separate pull request to park the file first.
Follow up, not in this PR
Someone with admin rights needs to mark
product-sdk: Changeset locationas required in Settings, Rules, Rulesets, on themainbranch ruleset. Until that happens the check reports red but does not block merging. Copy the check name from a completed run rather than typing it, because a ruleset entry that matches no job leaves every pull request stuck on "Expected, waiting for status to be reported".