[Fleet Monitor] petry-projects/google-app-scripts — .github/workflows/agent-shield.yml #391

Activity

1. don-petry

   added

   health-check

   dev-leadFor dev-lead agent pickupFor dev-lead agent pickup

   fleet-tracker

   on Jun 15, 2026
2. don-petry commented on Jun 15, 2026

   

   don-petry

   on Jun 15, 2026

   CollaboratorAuthor

   More actions

   Dev-Lead: Root-Cause Analysis — agent-shield.yml is healthy (false-positive degradation)

   I investigated the reported 33.3% failure rate (12 / 36 runs) for .github/workflows/agent-shield.yml. The workflow itself has zero genuine failures. The degraded status is a measurement artifact.

   Findings

   Over the last 100 agent-shield.yml runs:

   Conclusion	Count
   success	88
   action_required	12
   failure / timed_out	0

   • All 12 non-success runs are action_required — i.e. runs awaiting manual GitHub Actions approval, not failed runs.
   • Every one of them originates from three stale dev-lead compliance PRs, all opened 2026-06-02:
     • feat: implement issue #271 — Compliance: unpinned-actions-pr-review-mention.yml #358 — dev-lead/issue-271-20260602-1216
     • feat: implement issue #237 — Compliance: unpinned-actions-auto-rebase.yml #360 — dev-lead/issue-237-20260602-1218
     • feat: implement issue #156 — Compliance: unpinned-actions-dependabot-automerge.yml #361 — dev-lead/issue-156-20260602-1219
   • These PRs modify .github/workflows/* files (action-pinning compliance), so GitHub gates their workflow runs behind manual approval, producing the action_required conclusion every time they are (re-)triggered.

   Why it shows as a failure

   .dev-lead/scripts/fleet_monitor.sh:123 classifies action_required as a failure:

   failed = [.[] | select(.conclusion == "failure" or .conclusion == "timed_out" or .conclusion == "action_required")] | length

   So 12 pending-approval runs ÷ 36 windowed runs = the reported 33.3%. The AgentShield scan never actually failed.

   Why there is no in-scope fix to agent-shield.yml

   agent-shield.yml is a thin caller stub. Its file header and .dev-lead/CLAUDE.md both state it must not be modified beyond the documented with: inputs (min-severity, agentshield-version, required-files, org-standards-ref). None of those inputs influence GitHub's approval gating, so no edit to this file can change the action_required outcome. The trigger events, uses: line, and job name are explicitly off-limits.

   Recommended remediation (all outside this file's editable surface)

   1. Clear the backlog: approve or close the three stale compliance PRs (feat: implement issue #271 — Compliance: unpinned-actions-pr-review-mention.yml #358, feat: implement issue #237 — Compliance: unpinned-actions-auto-rebase.yml #360, feat: implement issue #156 — Compliance: unpinned-actions-dependabot-automerge.yml #361). Once they stop re-triggering, the action_required runs disappear and the rate returns to 0%.
   2. Fix the classifier at the source (preferred long-term): in the central petry-projects/.github-private copy of fleet_monitor.sh, exclude action_required from the failed set (it is an administrative pending-approval state, not a workflow defect). This affects all monitored workflows, so it belongs in the central repo rather than this stub-only issue.
   3. Repo Actions setting: review the "require approval to run workflows" policy for these bot-authored PRs so workflow runs are not parked in action_required.

   Conclusion

   No code change is made in this repo: the only file in scope (agent-shield.yml) is a protected thin stub with no applicable input, and the genuine fixes live in the central tooling / PR-triage and repo-settings surfaces noted above. Phase 2 (TDD) is intentionally skipped — there is no behavioral change to test.
3. don-petry commented on Jul 15, 2026

   

   don-petry

   on Jul 15, 2026

   CollaboratorAuthor

   More actions

   ✅ Auto-resolved by Fleet Monitor. This workflow's failure rate has been below the 10% threshold (or the workflow was removed) since 2026-06-15 (30 days) — the monitor stopped flagging it. Closing. It will reopen automatically if the workflow crosses the threshold again.
4. don-petry

   closed this as completedon Jul 15, 2026