Simplify/Clarify when prebuilds get triggered

[svenefftinge]

The logic for when prebuilds happen is quite confusing and also somewhat wrong.

We are currently listening on two kinds of events: 1) "pull_request.opened" | "pull_request.synchronize" | "pull_request.reopened" 2) "push"

They are somewhat overlapping but react differently depending on the config. For 1) "pull_request.opened" | "pull_request.synchronize" | "pull_request.reopened"

We run a prebuild if pullRequests in the prebuilds section is true (which is the default)

2) "push" If the main branch got pushed, we run a prebuild if master is true (which is default) For other branches we only run a prebuild if branches was explicitly set to true (it's false by default)

So pushing to branches doesn't always trigger a prebuild, but fiddling with an associated the PR would. I believe we should only prebuild on push and use the PR events purely to do checks, etc.

[svenefftinge]

Also our github-enterprise integration doesn't respect the prebuilds section in the gitpod.yml.

I believe we should remove/deprecate the prebuild section in the .gitpod.yml and make it configurable on the project in a hoster-independent manner. Also separating the prebuild mechanics from sending signal back to the git host (i.e. checks or comments)

[svenefftinge]

Also our github-enterprise integration doesn't respect the prebuilds section in the gitpod.yml.

Fixed in https://github.com/gitpod-io/gitpod/pull/16141

[geropl]

We sometimes have cases where (multiple owner) Teams/Orgs manage to register two kinds of webhooks (GitHub App and GHE-compatible webhook registration), which results in too many prebuilds being triggered.

Workaround:

• manually unregistering the webhook on GitHub
• disable Prebuilds for branches (default config of the .gitpod.yml)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.