Lari Can we configure CI in a way that it does not trigger the PR validation if the PR is in draft status?
Or another way would be that we do not trigger the validation at PR creation, but only when you issue a special command IIRC the Netty project works this way. It will be also safer, especially if only committers can trigger the validation, because this way we are sure that we are spending resources only for PR that have been reviewed. Your idea will help people in running the full suite in their personal forks Enrico Il Ven 19 Mar 2021, 18:21 Jonathan Ellis <jbel...@gmail.com> ha scritto: > Is it worth adding this to the Contributing doc page? > https://pulsar.apache.org/en/contributing/ > > On Fri, Mar 19, 2021 at 7:37 AM Lari Hotari <lar...@sagire.fi> wrote: > > > Dear Pulsar community members, > > > > I'm very happy to see a lot of activity in Pulsar development. This is a > > positive thing. > > The negative impact of this is that it adds more load to the GitHub > > Actions based Pulsar CI. > > We have been seeing long build queues and slow feedback from Pulsar CI > > recently. > > > > Since we cannot add more resources to Pulsar CI, we need to find other > > ways to reduce the load on Pulsar CI. > > Every developer can help reduce the load on Pulsar CI. > > Please don't open a PR to apache/pulsar when the work is in very initial > > stages. > > Every push to the pull request branch will trigger a lot of concurrent > > builds (about 25). > > By reducing the amount of PR pushes you can reduce the load on Pulsar CI. > > > > You don't have to stop developing and using CI for getting feedback. > There > > is a better way to get CI feedback for early stages of development. The > > secret is that everyone has their personal CI on GitHub! > > Please take use of it when you have large changes which stay in WIP for > > long periods of time, and you push a lot of changes before the actual > > reviews start. > > > > Here are instructions to use your personal CI on GitHub. > > > > 1. Push your intended pull request changes to a new branch in your fork > > (the usual way you do it). > > 2. Open a pull request to your own fork. > > > > A.) These are the instructions for CLI: > > > > Install GitHub CLI from https://cli.github.com/ and configure it. > > With GH CLI, there's an easy way to open the PR to your own fork with a > > single command: > > > > gh pr create --repo=your_github_id/pulsar --base master --head > > your-pr-branch -f > > > > B.) You can also create a PR to your own fork in the GitHub UI when > > opening a new PR. To do so, first click on "compare across forks" and > then > > choose your own fork as both the fork repository and head repository: > > [image: image.png] > > > > > > Notice: > > It's worth keeping your master branch in sync with apache/pulsar's master > > so that the PR diff will be reasonable in your own fork. > > > > Here's one way to sync your fork's master branch with apache/pulsar's > > master branch: > > Let's say if you have git remotes called "upstream" for apache/pulsar > and > > "forked" for your fork, with these commands, > > you synchronize your fork's remote master branch with apache/pulsar's > > master branch: > > > > # replace "upstream" with the name of the git remote for apache/pulsar > > # replace "forked" with the name of the git remote for your fork of > pulsar > > git fetch upstream > > git push -f forked upstream/master:master > > > > > > When you finally want to create a PR to apache/pulsar, it can be started > > from the command line (this will open a browser for filling in the PR > > details): > > > > gh pr create --repo=apache/pulsar --base master --head your-pr-branch > --web > > > > > > I hope this helps in getting started with your personal Pulsar CI so that > > you can help reduce the load on actual Pulsar CI. > > > > Please continue sending a lot of PRs! :) > > > > BR, Lari > > > > > -- > Jonathan Ellis > co-founder, http://www.datastax.com > @spyced >
