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.

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?

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.

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.

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.?

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

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.

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?

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.

Oh, I see :)
That was the solution we would have gone with.