[jddunn]

What changed

ci.yml gets a first job, changed (ubuntu-latest, no checkout). On a scheduled run it reads the newest earlier run of this workflow on master (whatever its result, a cancelled run aside) and, when master is still at that run's commit, pre-check skips, and with it every job that needs it; all-checks keeps always() and skips on that answer too. A push, a pull request or a dispatch always runs, and a lookup that fails runs the suite.

The daily run repeated the full suite on the same commit, 1740ce4a, day after day (about 10 minutes each) until GitHub disabled the schedule: 23127451256, 23177567976, 23228346090, 23279071437, 23328281049, 23371351877.

Follow-up 8b657405, from the reviews: a re-run of a scheduled run (github.run_attempt above 1) always runs; a skip check that fails or gives no answer runs the work (!cancelled() && needs.changed.outputs.run != 'false'); the lookup reads the newest 100 runs instead of 20.

Issue

No issue

Tests

No local run (CI-only rule). The job graph was read back from the YAML. This pull request's own run shows changed answering run=true for a pull request.

Not merged on purpose: a push to master here deploys the docs to GitHub Pages (docs-deploy) and can bump the version (version-bump-push.yml). It stays open for a deliberate merge.

Summary by Sourcery

Avoid rerunning the full CI suite on scheduled runs when the branch has not changed since the previous workflow run.

Enhancements:

• Skip scheduled CI runs when the target branch has not changed since the latest eligible workflow run, while continuing normal execution for other events and lookup failures.

CI:

• Add a lightweight CI gate that conditionally prevents unchanged scheduled runs from starting the full job suite.

[sourcery-ai]

Reviewer's Guide

Configuration

Add a scheduled-run history check and use its result to skip the CI jobs when the branch has not moved, while allowing other events and failed checks to proceed.

• .github/workflows/ci.yml L31-77, L523-524

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[github-actions]

🏷️ Auto-labeling complete!

Applied labels: area: ci/cd, github, ci, size: S

Labels help us categorize and prioritize PRs. You can manually add or remove labels as needed.

[sourcery-ai]

Hey - I've found 5 issues

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path=".github/workflows/ci.yml" line_range="76" />
<code_context>
   pre-check:
     name: Pre-checks
+    needs: changed
+    if: needs.changed.outputs.run == 'true'
     runs-on: ubuntu-latest
     steps:
</code_context>
<issue_to_address>
**Required checks pass without tests**

When the `changed` job fails or times out before publishing `run`, `needs.changed.outputs.run` is empty, so `pre-check` and its dependent jobs skip, and `all-checks` skips instead of reporting the failure; the required check appears successful without running the suite.

Make the final check fail when `changed` fails or omits `run`, rather than treating the empty output as a skip.

Also at `.github/workflows/ci.yml:56-58`, `.github/workflows/ci.yml:523`.
</issue_to_address>

### Comment 2
<location path=".github/workflows/ci.yml" line_range="57-58" />
<code_context>
+          run=true
+          if [ "$EVENT" = schedule ]; then
+            if wf=$(gh api "repos/$REPO/actions/runs/$RUN_ID" --jq .workflow_id) &&
+               last=$(gh api "repos/$REPO/actions/workflows/$wf/runs?branch=$BRANCH&per_page=20" \
+                 --jq "[.workflow_runs[] | select(.id != $RUN_ID and .conclusion != \"cancelled\" and .event != \"pull_request\")][0].head_sha // \"\""); then
+              if [ "$last" = "$SHA" ]; then
+                run=false
</code_context>
<issue_to_address>
**Scheduled checks skip uncovered commits**

When the matching same-SHA run is failed, queued or in progress and later cancelled, or is a newer duplicate run, the selector assigns `last` from a run that is not an earlier successful completion, and the `last == SHA` check sets `run=false`; the scheduled suite skips a commit without a successful earlier run covering it.

Select only completed successful runs earlier than the current run before comparing their SHAs.
</issue_to_address>

### Comment 3
<location path=".github/workflows/ci.yml" line_range="57-58" />
<code_context>
+          run=true
+          if [ "$EVENT" = schedule ]; then
+            if wf=$(gh api "repos/$REPO/actions/runs/$RUN_ID" --jq .workflow_id) &&
+               last=$(gh api "repos/$REPO/actions/workflows/$wf/runs?branch=$BRANCH&per_page=20" \
+                 --jq "[.workflow_runs[] | select(.id != $RUN_ID and .conclusion != \"cancelled\" and .event != \"pull_request\")][0].head_sha // \"\""); then
+              if [ "$last" = "$SHA" ]; then
+                run=false
</code_context>
<issue_to_address>
**Scheduled reruns skip the suite**

When someone chooses “Re-run all jobs” for a scheduled run and an earlier eligible run has the same SHA, the filter excludes the run being retried, then finds an earlier run with the same SHA and sets `run=false`. Re-running all jobs therefore skips the checks the caller is trying to rerun.

Allow scheduled reruns to proceed instead of applying the unchanged-commit gate.
</issue_to_address>

### Comment 4
<location path=".github/workflows/ci.yml" line_range="60" />
<code_context>
+               last=$(gh api "repos/$REPO/actions/workflows/$wf/runs?branch=$BRANCH&per_page=20" \
+                 --jq "[.workflow_runs[] | select(.id != $RUN_ID and .conclusion != \"cancelled\" and .event != \"pull_request\")][0].head_sha // \"\""); then
+              if [ "$last" = "$SHA" ]; then
+                run=false
+                echo "$BRANCH is at $SHA, which the last run of this workflow took: nothing changed, the run ends here."
+              else
</code_context>
<issue_to_address>
**Nightly checks miss dependency regressions**

When an upstream dependency changes while the repository commit stays the same, the unchanged-SHA check sets `run=false`, so the scheduled test matrix does not install and test the newly released dependency; regressions remain undetected until another event runs CI.

Keep scheduled dependency checks running when the repository SHA is unchanged.
</issue_to_address>

### Comment 5
<location path=".github/workflows/ci.yml" line_range="58" />
<code_context>
+          if [ "$EVENT" = schedule ]; then
+            if wf=$(gh api "repos/$REPO/actions/runs/$RUN_ID" --jq .workflow_id) &&
+               last=$(gh api "repos/$REPO/actions/workflows/$wf/runs?branch=$BRANCH&per_page=20" \
+                 --jq "[.workflow_runs[] | select(.id != $RUN_ID and .conclusion != \"cancelled\" and .event != \"pull_request\")][0].head_sha // \"\""); then
+              if [ "$last" = "$SHA" ]; then
+                run=false
</code_context>
<issue_to_address>
**Scheduled runs repeat the full suite**

When the 20 newest runs are excluded by the filter and an older eligible run has the current SHA, the API request limits results to 20 runs before `jq` removes excluded runs, so `last` is empty and `run=true`; the scheduled run repeats the suite unnecessarily.

Paginate through workflow runs until the newest eligible run is found before comparing its SHA.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

[github-actions]

🎉 Version bumped!

• Version: →
• Bump type:
• Tag:

The release workflow will be triggered automatically.