[bc1cindy]

renames the job to validate-commits and adds merge_group, so the required check reports in prs and in the merge queue. it also checks every commit in the range, like fungi does.

fixes #69

[github-actions]

range-diff for force push fc2c47a08e → 5ffc119b64 October 19, 2026 13:12 UTC: 1 modified

^{reproduce: git range-diff 32edbfe..fc2c47a 32edbfe..5ffc119}

1:  fc2c47a08e ! 1:  5ffc119b64 Validate each pull request commit in CI

1: fc2c47a08e ! 1: 5ffc119b64 Validate each pull request commit in CI

@@ Commit message
  ## .github/scripts/fetch-validation-history.sh (new) ##
 @@
 +#!/usr/bin/env bash
-+#
-+# This helper ensures that shallow checkouts (which are preferred in CI) are
-+# sufficiently deep to inspect every commit in the range, by deepening until
-+# every commit that is not an ancestor of base but is an ancestor of the merge
-+# tip is within the shallow commit boundary.
 +
 +set -euo pipefail
 +
 +base=${1:?Usage: fetch-validation-history.sh <base-sha>}
 +head=$(git rev-parse HEAD)
 +
-+# ensure base commit is fetched
 +if ! git cat-file -e "$base^{commit}" 2>/dev/null; then
 +  git fetch --no-tags --depth=1 origin "$base"
 +fi
@@ .github/scripts/fetch-validation-history.sh (new)
 +base=$(git rev-parse "$base^{commit}")
 +shallow_file=$(git rev-parse --git-path shallow)
 +
-+# git merge-base --is-ancestor $base $head doesn't mean all the commits are present.
-+#
-+# Once the shallow boundary can no longer affect the range, no deepening is required:
-+#
-+# 1. No commit in the range lacks parents, because shallow boundary commits are
-+#    grafted with no parents. (note: merging unrelated histories will break
-+#    this) and a true root inside the range means the base side has not been
-+#    deepened down to the fork point yet.
-+#
-+# 2. Every parentless commit on the base side is an ancestor of every join,
-+#    i.e. of every excluded parent of a range commit.  Otherwise a commit in
-+#    the range may still be an ancestor of $base through history that has not
-+#    been fetched: it would have to be an ancestor of that parentless commit
-+#    and a descendant of a join, which is impossible once 2 holds.
++# Deepening is needed until no range commit can reach $base through unfetched history.
 +range_needs_deepening() {
 +  [[ -s $shallow_file ]] || return 1
 +
@@ .github/workflows/checks.yml: concurrency:
    cancel-in-progress: true
  jobs:
 -  check:
-+  # The main ruleset requires a check with this job's name.
 +  validate-commits:
      runs-on: ubuntu-latest
 -    timeout-minutes: 30

[arminsabouri]

Rename the job, run it in the merge queue, and make the name true by checking each commit in the range, as fungi does.

Can we split this out in way? Or does it all have to apply at the same time? review is out primary bottleneck and it would be much easier for me to review a renaming of a ci job than the entirerty of this PR? in short, Can we unblock ci on the other prs by just renaming the file? or rename the rule set ?

[arminsabouri]

updated the ruleset from validate-commits to checks. Lmk if this unblocks until @Mshehu5 can review this

[yuval-block]

my bad i copied the rule from the monorepo and forgot that this is sensitive to the specific checks. thank you!

[github-actions]

range-diff for force push 5ffc119b64 → ba3405954d October 19, 2026 19:46 UTC: 1 unchanged

^{reproduce: git range-diff 32edbfe..5ffc119 344b072..ba34059}

1:  5ffc119b64 = 1:  ba3405954d Validate each pull request commit in CI