Don't run full build on schedule, run it for "ready" label

[zbynek]

This implements @niloc132 's idea to run full build when a specific label is present. Also removes the scheduled build as it's enough to build each commit to main once (over the last year scheduled builds did not detect any flaky issues with GWT itself, they only fail sometimes because of some strange Ant issue).

Demonstration PR: zbynek#4

[niloc132]

If I understand this correctly, it roughly says "If a PR has a label change or has code pushed to it, run the full check if the ready label is present".

The ability to add a label is limited to a certain group of contributors - I'll assume for now that all of those users are trusted to be able to do anything they want (such as publish artifacts with the keys that build has access to). This does at least limit an untrusted attacker from being able to create a malicious PR.

But it does not prevent an attacker from creating a seemingly-helpful PR, then wait for the ready label to be added, and then push a malicious commit - the build will helpfully run right away.

I'm not sure how to defend against that, aside from something like "if the user isn't trusted, revoke the label as soon as an early build step" coupled with a "this build can never run concurrently on two commits of the same PR".

[zbynek]

"If a PR has a label change or has code pushed to it, run the full check if the ready label is present".

Exactly.

But it does not prevent an attacker from creating a seemingly-helpful PR, then wait for the ready label to be added, and then push a malicious commit - the build will helpfully run right away.

Is this in any way different from the quick PR build that runs on each commit of each PR (after initial approval)?

[niloc132]

I don't think it is just initial approval, but after each change I (or someone else) must click the approve-workflow-run button?

It looks like we have this configured today to only apply until the user gets their first PR landed, then later PRs are assumed-good. My gut reaction is that this isn't safe enough, but maybe I need to be a little better educated here...

[zbynek]

So the risks here are

• someone uses GWT's credentials to upload something harmful to Sonatype -- likely not an issue since

Anyone with collaborator access to this repository can use these secrets and variables for actions. They are not passed to workflows that are triggered by a pull request from a fork.
-- https://github.com/gwtproject/gwt/settings/variables/actions

• someone spams the CI and makes GWT run out of CI quota -- I seriously doubt anyone would spend time getting a useful PR merged just to do that. I don't remember that happening in orgs that have more PR traffic than gwt.
• am I missing something else?

[niloc132]

Note that with this removed, we will no longer publish to sonatype snapshots - the steps below use this check:

if: ${{ github.event_name == 'schedule' && github.repository_owner == 'gwtproject' && matrix.java-version == '21' }}

This check is far from perfect - but as schedule only runs on the default branch, we don't have to worry about pushes to release/* overwriting latest HEAD-SNAPSHOT. To finish this patch and let a push event replace the schedule event for publishing, we'll have to make sure the GWT_VERSION env var makes sense too.

[zbynek]

New version pushed that should run this only when pushed to main. As I understand there are currently no Sonatype snapshots for release/* branches so maybe we can keep it like that for now?