feat(check-commits): report WIP commits as a separate check

[javier-godoy]

Refs FlowingCode/AddonsInternal#99
Depends on FlowingCode/action-conventional-commits#3 — merged.

A Pull Request with WIP commits must not be merged, but that is an expected state of an
unfinished branch rather than an error. Reporting it with the same failure as an invalid
commit message made the two indistinguishable.

WIP commits no longer fail the conventional commits step. They are reported as a separate
wip-commits check run with the action_required conclusion, which keeps the merge blocked
without marking the Pull Request as failing.

As a side effect, the version and Semantic Versioning checks now run for Pull Requests that
contain WIP commits, where previously the WIP failure skipped them.

Validated on javier-godoy/test-repo

Every open pull request there was re-run on 2026-09-15 against dd72611, the head of this
branch, and FlowingCode/action-conventional-commits at master, where #3 is now merged — so
the table below is what this workflow reports in its merged configuration, with no branch
pinning left anywhere.

check-commits / check-commits is the job's own check run, and it fails whenever the analysis
found anything to report, WIP commits included, because the script calls core.setFailed so the
pull request is marked as failing. What this branch changes is not that the job stays green: it
is that wip-commits says which problem it was, and concludes action_required rather than
failure when the branch can be squashed at merge time. semver-alignment and wip-commits
are created by this workflow and carry the verdict; the titles below are theirs.

Pull request	Scenario	check-commits	semver-alignment	wip-commits	mergeable_state
javier-godoy/test-repo#13	valid commit message	✅ success	Consistent: PATCH change	No Work-in-Progress (WIP) commits	clean
javier-godoy/test-repo#12	one invalid commit message	❌ failure	The semantic versioning level is unknown	No Work-in-Progress (WIP) commits	unstable
javier-godoy/test-repo#17	every commit message invalid	❌ failure	The semantic versioning level is unknown	No Work-in-Progress (WIP) commits	unstable
javier-godoy/test-repo#11	one non-WIP commit, then one WIP	❌ failure	Consistent: NONE change	🚧 Must squash WIP commit	unstable
javier-godoy/test-repo#25	one non-WIP commit, then two WIP	❌ failure	Consistent: NONE change	🚧 Must squash WIP commits	unstable
javier-godoy/test-repo#24	every commit is a WIP commit	❌ failure	Consistent: NONE change	🚧 Must consolidate WIP commit	unstable
javier-godoy/test-repo#28	breaking change, no version bump	❌ failure	🚫 MAJOR version required	No Work-in-Progress (WIP) commits	unstable
javier-godoy/test-repo#29	new feature, no version bump	❌ failure	🚫 MINOR version required	No Work-in-Progress (WIP) commits	unstable
javier-godoy/test-repo#30	breaking change with a matching version bump	✅ success	Consistent: MAJOR change	No Work-in-Progress (WIP) commits	clean
javier-godoy/test-repo#14	breaking change + WIP commit, no version bump	❌ failure	🚫 MAJOR version required	🚧 Must consolidate WIP commit	unstable
javier-godoy/test-repo#19	fork — invalid commit message	❌ failure	—	—	unstable
javier-godoy/test-repo#20	fork — non-WIP commit, then two WIP	❌ failure	—	—	unstable
javier-godoy/test-repo#21	fork — valid commit messages	✅ success	—	—	clean

A WIP commit does not affect the semantic versioning level: it neither raises it nor renders
it unknown, because it is going to be squashed into a commit whose own type settles the
level. javier-godoy/test-repo#11, #24 and #25 therefore report the level of their non-WIP
commits. A commit message that could not be parsed is different — the level it would have
settled is unknown, so the level as a whole becomes a lower bound. A lower bound cannot
confirm that a version is consistent, but it can still contradict one, which is why
javier-godoy/test-repo#14 keeps its MAJOR failure and javier-godoy/test-repo#12 reports the
level as unknown rather than as the NONE its one readable commit describes.

master in that repository is not protected, so no check is required and every failing pull
request reads unstable rather than blocked. An earlier manual run with wip-commits added
to the required checks did report blocked; that is recorded here as an observation, not as a
row the table above reproduces.

javier-godoy/test-repo#26 and javier-godoy/test-repo#27 also exist but call the action directly
rather than through this workflow, so they exercise the action's own reporting and say nothing
about this branch.

The suite covers both caller configurations, on a repository whose default workflow permission
is read-only. The ten same-repository pull requests declare contents: read + checks: write
on the calling job and get the two check runs. The three fork pull requests declare nothing at
all and still run, because this workflow asks for no permissions of its own: there is nothing
for a read-only caller to refuse. Their check runs are missing for an unrelated reason — the
workflow skips creating them on a fork, whatever the caller granted — so the verdict travels
through the annotations and the job's own conclusion.

It also confirms that the version and Semantic Versioning steps now run on pull requests that
contain WIP commits: javier-godoy/test-repo#14 reports a semver failure and a WIP failure
together, where previously the WIP failure skipped the version check.

The caveat still holds: mergeable_state is unstable, not clean, so GitHub counts
action_required as a non-successful check and the pull request reads "Some checks were not
successful" rather than being green.

🤖 Generated with Claude Code