Add scheduled workflow to restart stale PR status checks

[Copilot]

Plan: Create Scheduled PR Status Check Workflow

• Explore existing workflows and understand patterns
• Create new workflow file: RestartPRStatusCheck.yaml
• Implement workflow to run every 72 hours (3 days)
• Add logic to query and restart stale checks
• Test and verify the workflow logic
• Address PR review comments (round 1)
  • Change job name to "Restart Stale PR Status Checks"
  • Use gh pr checks instead of fetching all workflow runs
  • Add failed attempts tracking and retry logic
• Address PR review comments (round 2)
  • Extract code to separate action file
  • Add GitHub Actions notice when no PRs found
  • Fix to use correct fields: state and bucket instead of status and conclusion
  • Remove unnecessary completedAt check
  • Use continue pattern for consistency
  • Add workflow run summary
• Address PR review comments (round 3)
  • Use gh run rerun instead of API call for simpler code
  • Remove redundant bucket check (state already implies bucket)
  • Remove unused headRefName property from PR list query
• Address PR review comments (round 4)
  • Remove unused $success variable
  • Exit with error code 1 if any PRs failed to be processed
  • Count failed PRs instead of failed retry attempts
• Address PR review comments (round 5)
  • Remove default parameter values from workflow
  • Add mergeable state filtering to only process MERGEABLE PRs
  • Use Invoke-CommandWithRetry from EnlistmentHelperFunctions for consistent retry logic
  • Include gh pr checks call in retry mechanism
• Address PR review comments (round 6)
  • Add WhatIf parameter to script
  • Keep WhatIf in script only, not exposed in action.yaml
  • Remove redundant checkout from action.yaml
  • Fix Int32 overflow for large run IDs
  • Add null check for GITHUB_STEP_SUMMARY
• Final verification

Summary

Adds a scheduled workflow that runs every 72 hours to automatically restart stale PR status checks. The workflow only processes PRs in MERGEABLE state and uses the repository's standard Invoke-CommandWithRetry function for robust error handling. Both fetching checks and triggering reruns use retry mechanisms with exponential backoff to handle transient failures. The workflow exits with an error if any PRs fail to be processed, ensuring issues are visible.

Key Features

• Mergeable PR Filtering: Only processes PRs in MERGEABLE state to avoid wasted effort
• Robust Retry Logic: Uses Invoke-CommandWithRetry from EnlistmentHelperFunctions.psm1 for consistent, well-tested retry behavior
• Error Tracking: Counts failed PRs (not retry attempts) and exits with error code 1 when failures occur
• Workflow Summary: Provides GitHub Actions job summary with success/failure counts (when running in GitHub Actions)
• WhatIf Mode: Available in script for future testing (not currently exposed through action interface)
• Efficient: No redundant checkout - uses workspace from calling workflow
• Large Run ID Support: Uses Int64 to handle run IDs larger than 2 billion
• Portable: Can run both in GitHub Actions and locally for testing

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

AB#619349

[mazhelez]

@copilot I get the following error out of a sudden when I run the script.

action.ps1: Cannot bind argument to parameter 'Path' because it is null.

It happens after some PRs a processed. Can you please investigate?

[Copilot]

@copilot I get the following error out of a sudden when I run the script.

action.ps1: Cannot bind argument to parameter 'Path' because it is null.
...

Fixed by adding null check for $env:GITHUB_STEP_SUMMARY before calling Add-Content. The error occurred because GITHUB_STEP_SUMMARY can be null when running outside GitHub Actions context or in certain execution scenarios. All summary writes are now wrapped in if ($env:GITHUB_STEP_SUMMARY) { ... }. Commit f274fa6.

[Copilot]

Pull request overview

This PR introduces a scheduled GitHub Actions workflow and supporting composite action to automatically detect and restart stale “Pull Request Status Check” runs on mergeable PRs, with retry logic and summarized reporting. It leverages the existing EnlistmentHelperFunctions module for consistent retry behavior and integrates cleanly with the repository’s existing PR validation workflow.

Changes:

• Add a scheduled workflow (RestartPRStatusCheck.yaml) that runs every three days (and via manual dispatch) to invoke a local composite action for restarting stale PR status checks.
• Add a composite action definition (RestartStalePRChecks/action.yaml) that wires inputs, environment, and execution of a PowerShell script.
• Implement a PowerShell script (RestartStalePRChecks/action.ps1) that lists open PRs, filters to MERGEABLE ones, inspects the “Pull Request Status Check” via gh pr checks, and conditionally reruns the workflow with robust retry logic, WhatIf support, and a GitHub Actions step summary.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
.github/workflows/RestartPRStatusCheck.yaml	Defines the scheduled and manually-triggerable workflow that calls the new composite action to restart stale PR status checks.
.github/actions/RestartStalePRChecks/action.yaml	Declares the composite action interface (inputs, env) and runs the underlying PowerShell script with appropriate GitHub context.
.github/actions/RestartStalePRChecks/action.ps1	Contains the core logic to query mergeable PRs, identify stale successful “Pull Request Status Check” runs, rerun them with Invoke-CommandWithRetry, and emit a textual and step summary, exiting non‑zero on failures.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The $failed counter is tracking failed PRs (incremented once per PR failure), but the summary and job summary label it as "Failed attempts", which is misleading. Consider updating the text (both here and in the GITHUB_STEP_SUMMARY section) to clarify that this is the count of PRs that could not be processed, not retry attempts.