Closed svenefftinge closed 1 year ago
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)
Also our github-enterprise integration doesn't respect the prebuilds section in the gitpod.yml.
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:
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.
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 istrue
(which is the default)2) "push" If the main branch got pushed, we run a prebuild if
master
istrue
(which is default) For other branches we only run a prebuild ifbranches
was explicitly set totrue
(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.