Skip to content

Add workflow that fails when Dependabot updates error #459

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
oschwald merged 1 commit into from
Jul 22, 2026
+43 −0
Merged

Add workflow that fails when Dependabot updates error #459

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 43 additions & 0 deletions .github/workflows/dependabot-failure-watcher.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,43 @@
name: Dependabot Failure Watcher

# Dependabot version updates run as GitHub Actions workflow runs named
# "Dependabot Updates". This scheduled job looks back over the past week for any
# of those runs that failed and fails itself if it finds one, so a silently-broken
# ecosystem surfaces as a red scheduled run instead of only a red triangle in the
# Dependabot tab that nobody checks.
#
# 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.
Comment on lines +9 to +11
Comment on lines +9 to +11

@coderabbitai coderabbitai Bot Jul 22, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 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)
PY

Repository: 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:

🌐 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:

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


on:
schedule:
- cron: "17 14 * * 3" # Wednesdays 14:17 UTC
workflow_dispatch:

permissions:
actions: read

jobs:
check-dependabot-runs:
runs-on: ubuntu-latest
steps:
- name: Fail if any Dependabot update failed in the last 8 days
env:
GH_TOKEN: ${{ github.token }}
REPO: ${{ github.repository }}
run: |
since=$(date -u -d '8 days ago' +%Y-%m-%dT%H:%M:%SZ)
failures=$(gh run list \
Comment on lines +29 to +31
--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\")]")
Comment on lines +31 to +36

@coderabbitai coderabbitai Bot Jul 22, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 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 -S

Repository: 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:

🌐 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

count=$(echo "$failures" | jq 'length')
if [ "$count" -gt 0 ]; then
echo "::error::$count failed Dependabot update run(s) in the last 8 days:"
echo "$failures" | jq -r '.[] | "- \(.displayTitle) (\(.createdAt))\n \(.url)"'
exit 1
fi
echo "No failed Dependabot update runs in the last 8 days."
Loading