A GitHub Action that waits for all commit statuses and checks to succeed or fail before proceeding.
github-action-wait-for-status is a GitHub Action that pauses workflow execution until all commit statuses and checks have either succeeded or failed. It solves the problem of workflows proceeding prematurely—like merging a pull request—before all validations (e.g., tests, linting) are complete. By polling GitHub's API, it ensures subsequent steps only run when the commit is fully verified.
Developers and DevOps engineers using GitHub Actions for CI/CD pipelines, particularly those automating processes like pull request merging, deployments, or quality gates that depend on external checks.
It provides a simple, configurable way to synchronize workflows with external CI systems and status checks, reducing race conditions and failed deployments. Unlike manual waiting or fixed delays, it dynamically responds to actual check outcomes.
Github Action that waits for successful commit status
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Continuously polls GitHub's API to track all commit statuses and checks, ensuring workflows only proceed after all validations are complete, as highlighted in the Status Monitoring feature.
Allows ignoring specific actions like itself using the ignoreActions option, preventing infinite waiting loops, which is essential for avoiding self-blocking in workflows.
Users can adjust the checkInterval to match CI job durations, optimizing for both short and long-running checks, as shown in the Flexible Timing section.
With the waitForCheck option, it accommodates external CI systems that may delay in reporting statuses, making it versatile for hybrid setups.
Provides a status output (success, failure, error, rate_limited) that can be used to conditionally control subsequent steps, enabling precise workflow logic.
Relies on periodic API polling which introduces latency and can hit GitHub's rate limits, as indicated by the rate_limited output, potentially slowing down workflows.
Always exits with code 0 unless something fails, requiring users to manually handle the status output for failures, adding complexity compared to actions with built-in error responses.
The ignoreActions option depends on exact job names from commit statuses, which can be error-prone if names are mistyped or change, leading to misconfigurations.