Add workflow that fails when Dependabot updates error#459
Conversation
Dependabot version update failures only surface as a red triangle in the Dependabot tab, which nobody checks. This weekly scheduled workflow fails if any "Dependabot Updates" run concluded with failure, startup_failure, or timed_out in the last 8 days, so a broken ecosystem surfaces as a red scheduled run that emails a human. See maxmind/device-android#61 for the reference implementation. Co-Authored-By: Claude Fable 5 <[email protected]>
📝 WalkthroughWalkthroughAdds a scheduled and manually triggered GitHub Actions workflow that checks the last eight days of Dependabot Updates runs and fails when recent failure-like conclusions are found. ChangesDependabot failure monitoring
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 Checkov (3.3.8).github/workflows/dependabot-failure-watcher.ymlTraceback (most recent call last): Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
Adds a scheduled GitHub Actions workflow to monitor recent “Dependabot Updates” workflow runs and fail when any have concluded with failure, startup_failure, or timed_out, so broken Dependabot automation becomes a visible failing scheduled run.
Changes:
- Added a weekly (Wednesday) scheduled workflow plus manual dispatch trigger.
- Queries the last ~8 days of “Dependabot Updates” runs via
gh run listand fails the job if any qualifying failures are found. - Prints a summarized list of failed runs (title, timestamp, URL) to aid triage.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| run: | | ||
| since=$(date -u -d '8 days ago' +%Y-%m-%dT%H:%M:%SZ) | ||
| failures=$(gh run list \ |
| # Runs entirely within this repo (no external service). A failed scheduled run | ||
| # emails the person who last edited the cron below. Note: GitHub auto-disables | ||
| # scheduled workflows after 60 days of repo inactivity. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/dependabot-failure-watcher.yml:
- Around line 31-36: The Dependabot run query in the failures collection must
not filter the 8-day window after an arbitrary 100-run cap. Pass the since
timestamp through gh run list’s created-time constraint and paginate or increase
the limit to cover the full window, adding --all if disabled workflows should be
included; retain the existing jq conclusion filtering and output fields.
- Around line 9-11: Update the comments near the scheduled cron in the workflow
to state that failure emails depend on enabled Actions notifications and are
sent to the workflow actor. Clarify that GitHub’s 60-day scheduled-workflow
auto-disable behavior applies only to public repositories.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 4db2c55f-ee9b-4704-8bf1-c79b9fb9f1bf
📒 Files selected for processing (1)
.github/workflows/dependabot-failure-watcher.yml
| # Runs entirely within this repo (no external service). A failed scheduled run | ||
| # emails the person who last edited the cron below. Note: GitHub auto-disables | ||
| # scheduled workflows after 60 days of repo inactivity. |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== File ==\n'
cat -n .github/workflows/dependabot-failure-watcher.yml
printf '\n== Relevant docs search ==\n'
python3 - <<'PY'
import urllib.parse, json, subprocess, textwrap, sys, os
queries = [
"site:docs.github.com GitHub Actions scheduled workflows auto-disabled after 60 days public repositories notifications actor",
"site:docs.github.com workflow actor scheduled workflows notifications GitHub Actions",
]
for q in queries:
print("\nQUERY:", q)
PYRepository: maxmind/libmaxminddb
Length of output: 2486
🌐 Web query:
GitHub Actions scheduled workflows notifications actor auto-disable 60 days public repositories docs
💡 Result:
GitHub automatically disables scheduled workflows in public repositories if there has been no repository activity for 60 consecutive days [1][2][3]. This is a policy designed to prevent unnecessary workflow runs on inactive repositories [1][4]. Key details of this policy include: - Trigger for Disabling: The 60-day timer is reset by repository activity, which typically includes pushing commits or other forms of direct repository interaction [4][3]. Simply commenting on issues or PRs is generally not considered sufficient to reset this timer [4]. - Automatic Nature: The disabling happens automatically without proactive notifications (such as emails or dashboard alerts) to repository maintainers [3]. - Re-enabling: Once a workflow is disabled due to inactivity, it must be re-enabled manually [3]. This can be done through the GitHub Actions user interface or by using the GitHub REST API [4][5]. - Best Practices: To mitigate the impact of this policy, many developers include a workflow_dispatch trigger in their scheduled workflows [3]. This allows them to manually trigger the workflow from the Actions tab, which can effectively re-enable the workflow without requiring a new code push [3]. In addition to this inactivity policy, scheduled workflows are also disabled by default when a public repository is forked [1][2].
Citations:
- 1: https://docs.github.com/actions/managing-workflow-runs/disabling-and-enabling-a-workflow
- 2: https://docs.github.com/en/[email protected]/actions/how-tos/manage-workflow-runs/disable-and-enable-workflows?tool=webui
- 3: https://jakeinsight.com/productivity/2026-03-29-github-actions-workflow-not-triggering-on-schedule/
- 4: https://stackoverflow.com/questions/67184368/prevent-scheduled-github-actions-from-becoming-disabled
- 5: https://cronpreview.com/guides/github-actions-cron-in-production
🌐 Web query:
site:docs.github.com GitHub Actions scheduled workflow actor notifications cron editor email
💡 Result:
In GitHub Actions, scheduled workflows are associated with an 'actor' who is the user responsible for triggering notifications [1][2][3]. This actor is typically the user who last modified the cron syntax in the workflow file [4][5][6]. The assignment of the actor and notification recipient follows these specific rules: - Default Behavior: Notifications for scheduled workflows are initially sent to the user who created the workflow [4][5][6]. - Modifications: If a different user updates the cron syntax within the workflow file, that user becomes the actor, and all subsequent notifications are sent to them instead [4][5][6]. - Re-enabling Workflows: If a scheduled workflow is disabled and later re-enabled, the user who performed the re-enabling action becomes the actor, overriding the user who last modified the cron syntax [4][5][6]. - Repository Events: Certain repository events, such as changing the default branch of the repository, can also change the actor associated with the workflow [1][2][3]. To receive email notifications for these workflow runs, you must have GitHub Actions notifications enabled in your personal notification settings [4][5][7]. You can configure your settings to receive notifications for all workflow runs or specifically for failed runs only [4][5][7]. If you are part of an enterprise using Enterprise Managed Users (EMU), the workflow will only run if the account associated with the current actor is active (i.e., not suspended or deleted) [1][2][3]. Removing a user from an organization does not necessarily prevent a workflow from running if that user remains the actor and their account status is otherwise active [1][2][3].
Citations:
- 1: https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows
- 2: https://docs.github.com/en/[email protected]/actions/reference/workflows-and-actions/events-that-trigger-workflows
- 3: https://docs.github.com/actions/using-workflows/events-that-trigger-workflows
- 4: https://docs.github.com/en/enterprise-cloud@latest/actions/concepts/workflows-and-actions/notifications-for-workflow-runs
- 5: https://docs.github.com/en/[email protected]/actions/concepts/workflows-and-actions/notifications-for-workflow-runs
- 6: https://docs.github.com/en/[email protected]/actions/concepts/workflows-and-actions/notifications-for-workflow-runs
- 7: https://docs.github.com/en/subscriptions-and-notifications/how-tos/managing-github-actions-notifications
Lines 9-11: Make the notification caveat precise. GitHub only emails scheduled-workflow failures when Actions notifications are enabled, and the recipient follows the workflow actor. The 60-day auto-disable caveat applies to public repositories only.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/dependabot-failure-watcher.yml around lines 9 - 11, Update
the comments near the scheduled cron in the workflow to state that failure
emails depend on enabled Actions notifications and are sent to the workflow
actor. Clarify that GitHub’s 60-day scheduled-workflow auto-disable behavior
applies only to public repositories.
Source: MCP tools
| failures=$(gh run list \ | ||
| --repo "$REPO" \ | ||
| --workflow "Dependabot Updates" \ | ||
| --limit 100 \ | ||
| --json conclusion,createdAt,displayTitle,url \ | ||
| --jq "[.[] | select((.conclusion == \"failure\" or .conclusion == \"startup_failure\" or .conclusion == \"timed_out\") and .createdAt >= \"$since\")]") |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the workflow around the reported lines
file=".github/workflows/dependabot-failure-watcher.yml"
wc -l "$file"
sed -n '1,220p' "$file"
# Find related workflow references
rg -n "Dependabot Updates|gh run list|created_since|since|--all|--limit" .github/workflows -SRepository: maxmind/libmaxminddb
Length of output: 2765
🌐 Web query:
gh run list limit applies before jq filter createdAt server-side --created disabled workflows --all official docs
💡 Result:
In the GitHub CLI command gh run list, the --limit flag applies server-side, meaning it restricts the number of workflow runs fetched from the GitHub API [1][2]. When you use filters like --created, --status, or --event, these are also applied server-side by the GitHub API before the data is returned to the CLI [3]. Because the API limits the results based on the combined criteria, applying a --limit (which defaults to 20) happens on the filtered set [1][2]. If you apply a --jq filter, that processing happens locally on your machine after the CLI has already received the results from the server [4]. Consequently, if you use --limit to fetch a small number of records and then try to use --jq to filter them further, you might end up with fewer results than expected (or even zero) because the API returned only the first N items that matched the server-side filters, and your jq expression then filtered those further [1][4]. Regarding other details: - The --created flag supports GitHub search syntax (e.g., ranges like ">=2024-01-01" or "2024-01-01..2024-02-01") [5][3]. - The --all flag is required if you want to include disabled workflows when using the -w (workflow) flag [1][2]. Without --all, gh run list will not fetch runs for disabled workflows [1][2].
Citations:
- 1: https://man.archlinux.org/man/gh-run-list.1.en
- 2: https://cli.github.com/manual/gh_run_list
- 3: Allow filtering workflow runs by date range in gh run list cli/cli#9042
- 4: Support filtering before applying template cli/go-gh#177
- 5: Improve help text for --created flag in gh run list cli/cli#13043
🌐 Web query:
site:cli.github.com gh run list --limit --created --all workflow disabled runs documentation
💡 Result:
To list workflow runs including those from disabled workflows using the GitHub CLI, use the gh run list command with the --all flag [1]. The command supports several flags for filtering and controlling the output [1]: - --all: Includes runs from disabled workflows [1]. Note that if you are using the -w (--workflow) flag to filter by a specific workflow name, you must also include the --all flag to ensure runs from that workflow are fetched if it is currently disabled [1]. - --limit : Sets the maximum number of runs to fetch (default is 20) [1]. - --created : Filters runs by the date they were created [1]. Example usage: gh run list --all --limit 50 --created ">=2026-01-01" For further details on command options, you can view the official documentation by running gh help run list in your terminal or visiting the GitHub CLI manual [1].
Citations:
Avoid missing failures past the first 100 runs. --limit 100 caps the returned runs before the local jq date filter runs, so failures in the 8-day window can be skipped once there are more than 100 Dependabot runs. Move the time constraint into --created, and paginate or raise the limit enough to cover the full window; add --all if disabled workflows are meant to be included.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/dependabot-failure-watcher.yml around lines 31 - 36, The
Dependabot run query in the failures collection must not filter the 8-day window
after an arbitrary 100-run cap. Pass the since timestamp through gh run list’s
created-time constraint and paginate or increase the limit to cover the full
window, adding --all if disabled workflows should be included; retain the
existing jq conclusion filtering and output fields.
Source: MCP tools
Add a weekly scheduled workflow that fails when any "Dependabot Updates" run concluded with
failure,startup_failure, ortimed_outin the last 8 days, so a silently-broken Dependabot ecosystem surfaces as a red scheduled run that emails a human instead of only a red triangle in the Dependabot tab that nobody checks.This is a copy of the reference change in maxmind/device-android#61, adjusted to run on Wednesdays and to also treat
timed_outas a failure.🤖 Generated with Claude Code
Summary by CodeRabbit