ci: add per-job timeout-minutes to the release notification workflow - #11
Merged
Merged
Conversation
Both notification jobs could previously run until the GitHub 6 h ceiling. A webhook POST that never returns therefore held a runner slot for hours. Each job now carries an explicit timeout-minutes. Rule: the budget is 3 x the job's observed p90 duration, rounded up to the nearest 5 minutes. Where 72 h of run history contains no completed sample for a job, the class default for that job's class is used instead. Both jobs below fall in the second case. .github/workflows/notify.yml discord_notify 15 class default (deploy/notify), unobserved slack_release_notify 15 class default (deploy/notify), unobserved No concurrency change: notify.yml is triggered by release:published, so each run corresponds to a distinct release and no run supersedes another. The other workflows in this repository already declare their own concurrency groups. Job names, job count and workflow triggers are unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ci: add per-job timeout-minutes to the release notification workflow
Both notification jobs could previously run until the GitHub 6 h
ceiling. A webhook POST that never returns therefore held a runner slot
for hours. Each job now carries an explicit timeout-minutes.
Rule: the budget is 3 x the job's observed p90 duration, rounded up to
the nearest 5 minutes. Where 72 h of run history contains no completed
sample for a job, the class default for that job's class is used
instead. Both jobs below fall in the second case.
.github/workflows/notify.yml
discord_notify 15 class default (deploy/notify), unobserved
slack_release_notify 15 class default (deploy/notify), unobserved
No concurrency change: notify.yml is triggered by release:published, so
each run corresponds to a distinct release and no run supersedes
another. The other workflows in this repository already declare their
own concurrency groups.
Job names, job count and workflow triggers are unchanged.
Part of the CI pool right-sizing programme; edits derived from 72 h of run history.