Did I read correctly, it doesn’t run if there are no labels? What about new contributors without permissions to label yet for a given PR?
If the GitHub/travis practices are already documented somewhere then can they be updated (once accepted) to have a centralized place for knowledge of this (and the available labels)? If they are not then is it worth starting to so folks have a centralized place instead of searching through PRs or emails? Maybe somewhere near here (1)? Or maybe a new page for GitHub similar to page for Jenkins (2) with GitHub and GitHub Actions and practices documented? References: (1) https://cwiki.apache.org/confluence/x/wBJ4CQ (2) https://cwiki.apache.org/confluence/x/VQ3HBg On Thu, Aug 11, 2022 at 8:20 AM Michael Bien <[email protected]> wrote: > On 11.08.22 11:21, Neil C Smith wrote: > > On Thu, 11 Aug 2022 at 00:23, Michael Bien <[email protected]> wrote: > >> Usually push only happens on merge (since that counts as push too), if > >> you sync two branches on our main repo (not from clone to main), you > >> would push into one branch and create a PR from it. Which means it > >> builds the same hash twice just for the PR (and a third time on merge). > >> You would see every check twice below the sync PR, one marked with push > >> and one with pull_request. Unfortunately it doesn't show that on closed > >> PRs and we don't have one open atm. > > I'm aware of the two checks. My point was that they're not the same > > hash, on GitHub or Travis, as far as I know. > > > > The branch tests run on the head of the delivery branch > > (refs/head/delivery). The sync PR tests run on the pending result of > > the merge to the base branch (refs/pull/<ID>/merge), eg. master. Now > > the result of merging to releaseXXX is usually not interesting. > > Testing on the result of merging to master can (and occasionally does) > > highlight concerns. Which we can then try to address *before* merging > > syncs to the two branches. PRs into delivery have usually been tested > > against delivery, not master. This is a reason for opening the sync > > PRs as soon as delivery has changes. > > > > This is somewhat of a tangent to your original post - just pointing > > out that full CI on sync PRs is deliberate at the moment. We could > > change procedures if you think there's a better way to achieve the > > above. > > I see - makes sense. So assuming the proposed changes make it in, > release managers would have to set the ci:all-tests label on the sync PR > to have the same result as today. > > regards, > > michael > > > > > Best wishes, > > > > Neil > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > For further information about the NetBeans mailing lists, visit: > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > -- Eric Bresie [email protected]
