ci(workflows): also run on reopened pull requests - #337
Merged
Conversation
An explicit `types:` list replaces GitHub's default `opened, synchronize, reopened` rather than extending it, so these workflows never ran when a pull request was reopened. Where such a workflow publishes a required status check, that leaves a reopened pull request permanently blocked: the check is absent rather than failed, no run exists to re-run, and the only way out is another push to the head branch. REQUIRED_CHECKS is not yet set for these repositories, so the gap is latent today — it goes live with RSRMID-2991. RSRMID-2998
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
1 participant
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.
Jira: https://centralnic.atlassian.net/browse/RSRMID-2998
Adds
reopenedto thepull_requesttrigger'stypes:list.Why
An explicit
types:list replaces GitHub's defaultopened, synchronize, reopened— it does not extend it. These workflows listedonly
openedandsynchronize, so reopening a pull request created no run atall.
Where such a workflow publishes a required status check, that leaves a
reopened pull request permanently blocked. The check is absent rather than
failed, so there is nothing to re-run, and the only way out is pushing another
commit to the head branch.
Why now, and why this is not urgent
REQUIRED_CHECKSis currently set for only four repositories (php-sdk,template, devcontainer-features, workspace) and none of them is affected —
php-sdk already lists
reopened. So the gap is latent today.It goes live the moment RSRMID-2991 fills
REQUIRED_CHECKSfor the remainingrepositories: these files become merge-blocking, and the failure surfaces as a
stuck pull request rather than a red check. Fixing it beforehand is a one-line
edit; afterwards it is a debugging session.
Scope
Option A of two — add the type explicitly, rather than deleting
types:andinheriting the default. Explicit keeps the file auditable by grep and does not
leave a merge gate defined by a GitHub default that could change. Applied
identically across all ten affected files so an absent
types:block staysunambiguous.
Found by enumerating every workflow file in the registered repositories plus
shareable-workflowsagainst their default branches: 10 correct, 54 with nopull_requesttrigger, 10 affected.whmcswas not readable and is unverified.No formatting changes are included. Four of these files already fail a
prettiercheck on their default branch, but prettier is neither a declareddependency nor gated in CI there — reformatting would bury a one-line fix in
unrelated churn.