-
Notifications
You must be signed in to change notification settings - Fork 121
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
base: main
Are you sure you want to change the base?
Conversation
@@ -25,7 +43,7 @@ env: | |||
|
|||
jobs: | |||
PregateCheck: |
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:
- When a draft PR is opened, no PR Build is triggered.
- When a draft PR is converted to "ready for review", a PR Build is triggered.
- When a non-draft PR is opened, a PR Build is triggered.
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?
By default, a workflow only runs when a pull_request event's activity type is opened, synchronize, or reopened
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.
Templates/Per Tenant Extension/.github/workflows/PullRequestHandler.yaml
Outdated
Show resolved
Hide resolved
https://github.com/microsoft/AL-Go/actions/runs/10140000167 |
The error is because the PullRequestHandler needs to be identical in the AppSource App template folder and in the Per Tenant Extension folder. Your PR only contains changes to the PTE folder. |
I think the PR makes sense. Big question is whether it should be possible to run builds on draft mode? with this PR, I guess it is always blocked? |
I do agree there needs to be a way to allow for the pipeline to run in draft mode. We could either run the workflow partially and exit as soon as possible, or supplement Update-Workflow with the ability to append or remove the draft condition. |
We could also create a setting called runPullRequestBuildOnDraftPR and default it to false? |
This PR adds a condition to "PullRequestHandler.yaml" that ensures pull requests in draft mode won't trigger the status check. This reduces unnecessary build workflows for feature branches. Additionally, the PR explicitly lists all types of the
pull_request_target
event. Listing the types isn't supposed to confirm each type as a valid reason to trigger the workflow, but rather to invite maintainers to judge which events can be ignored for this workflow.Resolves #1051