Skip to content
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
wants to merge 8 commits into
base: main
Choose a base branch
from
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,11 @@ name: 'Pull Request Build'
on:
pull_request_target:
branches: [ 'main' ]
types:
- synchronize
- opened
- reopened
- ready_for_review

concurrency:
group: ${{ github.workflow }}-${{ github.event.pull_request.number }}
Expand All @@ -25,14 +30,14 @@ env:

jobs:
PregateCheck:
Copy link
Collaborator

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.

Copy link
Contributor Author

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?

Copy link
Collaborator

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.

Copy link
Contributor Author

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.

Copy link
Collaborator

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:

  1. When a draft PR is opened, no PR Build is triggered.
  2. When a draft PR is converted to "ready for review", a PR Build is triggered.
  3. 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.?

Copy link
Collaborator

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

Copy link
Contributor Author

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.

Copy link
Collaborator

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?

Copy link
Contributor Author

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.

Copy link
Collaborator

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.

if: (github.event.pull_request.base.repo.full_name != github.event.pull_request.head.repo.full_name) && (github.event_name != 'pull_request')
if: (github.event.pull_request.base.repo.full_name != github.event.pull_request.head.repo.full_name) && (github.event_name != 'pull_request') && (github.event.pull_request.draft == false)
runs-on: windows-latest
steps:
- uses: microsoft/AL-Go-Actions/VerifyPRChanges@main

Initialization:
needs: [ PregateCheck ]
if: (!failure() && !cancelled())
if: (!failure() && !cancelled()) && (github.event.pull_request.draft == false)
runs-on: [ windows-latest ]
outputs:
githubRunner: ${{ steps.ReadSettings.outputs.GitHubRunnerJson }}
Expand Down Expand Up @@ -81,7 +86,7 @@ jobs:

Build:
needs: [ Initialization ]
if: (!failure()) && (!cancelled()) && fromJson(needs.Initialization.outputs.buildOrderJson)[0].projectsCount > 0
if: (!failure()) && (!cancelled()) && fromJson(needs.Initialization.outputs.buildOrderJson)[0].projectsCount > 0 && (github.event.pull_request.draft == false)
strategy:
matrix:
include: ${{ fromJson(needs.Initialization.outputs.buildOrderJson)[0].buildDimensions }}
Expand All @@ -104,7 +109,7 @@ jobs:

StatusCheck:
needs: [ Initialization, Build ]
if: (!cancelled())
if: (!cancelled()) && (github.event.pull_request.draft == false)
runs-on: [ windows-latest ]
name: Pull Request Status Check
steps:
Expand Down
Loading