-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Skip Pull Request check in draft mode #1132
Open
cegekaJG
wants to merge
8
commits into
microsoft:main
Choose a base branch
from
cegekaJG:pull-request-draft
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
0d43293
feat: Skip Pull Request Handler for draft PRs
cegekaJG 4adb96c
chore: Explicitly list all trigger event types in Pull Request Handler
cegekaJG 2cb9de1
chore: Remove unused types from event trigger
cegekaJG 22fea5b
feat: Add draft condition check to all jobs of PullRequestHandler.yaml
cegekaJG 0ef6b6d
Merge branch 'main' into pull-request-draft
cegekaJG 8cadbb2
Merge branch 'main' into pull-request-draft
cegekaJG bfbcdfb
Merge branch 'main' into pull-request-draft
cegekaJG d4d4db3
Merge branch 'main' into pull-request-draft
freddydk File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
PregateCheck
exists to fail external PRs (from forks) that edit certain files.With the new check the check will not be triggered for draft PRs, which is not desirable behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see the sense in running status checks for PRs in draft mode. Even if the PR was editing blacklisted files, there's no risk of introducing breaking changes since it's not ready to be merged to begin with, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Running status checks on draft have some advantages.
E.g. some developers prefer to have green build before setting the PR as ready to review. Others, want to get feedback as soon as they start developing.
Since GitHub decided to run PR workflows even on draft PRs, we decided that there isn't anything to lose there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My motivation for this change is the fact that runtimes can be very long and I want to save as much compute time on GitHub's runners as possible. I understand that this can be mitigated by pushing as little as possible, but I'd like our developers to have the ability to keep their remote branches up to date without restrictions. Additionally, we have custom workflows that automate some processes by preparing pull requests, and those can end up in draft mode if manual input is required - any status checks would be pointless at this stage, so I'd like to avoid them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a valid point, but, as I said, that might not be aligned with what other developers what to experience.
So, generally you want to following scenarios to be supported:
With your changes, 1. will not be satisfied, because GitHub doesn't differentiate between draft and non-draft PRs for the "opened" trigger. (Feel free to test that).
If a PR Build isn't triggered when the PR is opened, then how would you cover 3.?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then how is it different from now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
ready-for-review
type. Without it, you wouldn't be able to run a check as soon as a PR leaves draft mode.I agree that I can't leave the current condition as-is, since the build-job is being triggered regardless of the result of the previous job, but I do think this change is necessary to ensure PRs behave correctly when moving between draft mode.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you elaborate a bit? Is the workflow skipped or is it never triggered?
My question was in regards of the triggers. If the default trigger types are opened, synchronize, or reopened, then why is the PR Build triggered on draft PRs in the first place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The triggers don't consider the status of the PR so the workflow is initiated all the same, but the jobs will be skipped because the
if
-condition isn't met.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I see :)
That was the solution we would have gone with.