Reduce email notifications on forks

[richard-cox]

• There's now roughly 10 notifications per day regarding failed automation runs
• Looks like these shouldn't be running in forks

We should

• Ensure they don't run in forks
• Which should stop the emails
  • note there's notifications for workflows that run but no jobs executed (i.e. all jobs were filtered out). we shouldn't get these either

Some that need updating

• Duplicate Code Detector
• Extension workflows - Release 2.8
• Extension workflows
• Extension workflows - Release 2.9
• Daily Repo Status
• Daily Accessibility Review
• Daily Test Improver
• Daily Issue Grooming
• Update Cloud Data

Bonus notifications

• valid-milestone-change
  • Improve valid-milestone-change workflow #17787

[github-actions]

🎯 Agentic Issue Triage

Summary: Scheduled/automation GitHub Actions workflows are triggering in forked repositories, generating ~10 unwanted email notifications per day. The fix is to add fork-detection guards to each affected workflow so they only run in the canonical rancher/dashboard repository.

📋 Analysis

Issue Type: Bug — CI/workflow infrastructure
Affected Area: GitHub Actions automation workflows (agentic & scheduled)
User Impact: Developers who have forked the repo receive noise email notifications daily from failed (or no-op) automation runs.

Two sub-problems to solve:

1. Workflows actively running jobs in forks (and failing due to missing secrets/context).
2. Workflows that run but skip all jobs (all jobs filtered out) — GitHub still sends a notification for these.

Affected Workflows:

• Duplicate Code Detector
• Extension workflows (main + Release 2.8 + Release 2.9)
• Daily Repo Status
• Daily Accessibility Review
• Daily Test Improver
• Daily Issue Grooming
• Update Cloud Data

🔧 Recommended Fix

For each affected workflow YAML file, add a repository guard. The most reliable approach is to add a top-level if condition on the job(s), or use a workflow condition:

Option A — Job-level guard (preferred for granular control):

jobs:
  my-job:
    if: github.repository == 'rancher/dashboard'
    runs-on: ubuntu-latest
    ...

Option B — Workflow-level env check (alternative):

on:
  schedule:
    - cron: '...'

jobs:
  my-job:
    if: ${{ github.repository_owner == 'rancher' && !github.event.repository.fork }}
    ...

⚠️ Note: Even with a single job guarded by if, GitHub can still send a "workflow run completed with no jobs" notification. To suppress this, ensure every job in the workflow has the guard — or consolidate to a single job with the check at the top.

To silence "no jobs ran" notifications, you may need to add a minimal sentinel job:

jobs:
  check-repo:
    runs-on: ubuntu-latest
    outputs:
      should_run: ${{ steps.check.outputs.should_run }}
    steps:
      - id: check
        run: echo "should_run=${{ github.repository == 'rancher/dashboard' }}" >> $GITHUB_OUTPUT
  main-job:
    needs: check-repo
    if: needs.check-repo.outputs.should_run == 'true'
    ...

✅ Sub-task Checklist

• Locate workflow YAML files for all 9 workflows listed in the issue
• Add if: github.repository == 'rancher/dashboard' guard to each affected job
• Verify the guard also suppresses the "no jobs ran" notification (test with a fork if possible)
• Duplicate Code Detector — add fork guard
• Extension workflows — add fork guard
• Extension workflows - Release 2.8 — add fork guard
• Extension workflows - Release 2.9 — add fork guard
• Daily Repo Status — add fork guard
• Daily Accessibility Review — add fork guard
• Daily Test Improver — add fork guard
• Daily Issue Grooming — add fork guard
• Update Cloud Data — add fork guard
• Confirm no existing fork guards are already present (avoid double-guarding)

📚 Useful Resources

• GitHub Docs: Context — github.repository
• GitHub Docs: Workflow syntax — jobs.<job_id>.if
• GitHub Community discussion on fork notifications — common pattern: if: github.repository == 'owner/repo'
• GitHub Docs: Skip workflow runs

Generated by Agentic Triage for issue #17489 · ● 148.2K · ◷

[aalves08]

From the Extensions workflows, they don't run on forks:

• All three workflows are triggered only by schedule (cron: "0 0 * * *"). GitHub Actions scheduled workflows only run on the default branch of the repository and do not run on forks unless manually enabled in the fork's Actions settings.

• Every job (except slack-message) has an explicit condition:
  if: ${{ github.repository_owner == 'rancher' }}

[richard-cox]

The extensions workflows cause various email notifications. Couple of examples

[richard-cox/dashboard] Run failed at startup: Test Extension workflows - Master (3.x) - master
Test Extension workflows - Master (3.x): No jobs were run
https://github.com/richard-cox/dashboard/actions/runs/25354096137
(note that all jobs are excluded, but an email is sent saying so)

[richard-cox/dashboard] Run failed: Test Extension workflows - Release 2.8 (1.x) - master
Test Extension workflows - Release 2.8 (1.x): Some jobs were not successful
https://github.com/richard-cox/dashboard/actions/runs/25353420643
(note that the slack job runs and fails)

I couldn't see anything in the schedule docs that mentioned fork's action settings, just the default branch. Is there another doc?

[github-actions]

🤖 Issue grooming questions

Thanks for filing this! The problem statement and the list of affected workflows are clear. To complete grooming, a couple of things are still needed:

1. Acceptance criteria — What does "fixed" look like in verifiable terms? For example:

   • The listed workflows must not trigger on any repository fork.
   • Contributors must not receive any email notifications from fork-triggered workflow runs (including runs where all jobs are filtered out).
     Could you add 1–3 explicit, testable acceptance criteria to the issue body?

2. Expected vs. actual behavior — A short description would help engineers and reviewers confirm the bug and validate the fix. For example:

   • Expected: Automation workflows only run in the upstream rancher/dashboard repository.
   • Actual: Workflows run (or produce filtered-job runs) in forked repositories, generating ~10 email notifications per day.
   • What event(s) trigger the unwanted runs? (e.g., push to a fork branch, scheduled cron, PR from fork?)

This comment was generated automatically to help gather the information needed to groom this issue.

Note

🔒 Integrity filter blocked 5 items

The following items were blocked because they don't meet the GitHub integrity level.

• deployment resource details page hangs #17488 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• [Fleet UI] Fleet Clusters page: Fleet workspace toggle button shows fleet-local instead of fleet-default when navigating back to the same page. #17425 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• [RFE] Add Restart option to selected containers on the Containers tab #17445 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• local-filter in PaginatedResourceTable does not work when switch the filter options which have the same amount of the record #15576 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• Feature Request: Support harvester-baremetal-container-workload clusters #12518 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

Generated by Daily Issue Grooming · ● 153.4K · ◷