Good suggestions. > Can we configure CI in a way that it does not trigger the PR validation if > the PR is in draft status?
Yes, that's possible. I guess this would be the solution: https://github.community/t/dont-run-actions-on-draft-pull-requests/16817/16 . Please create an GH issue about this change request. That way it will be easier to track it. > 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. Because of security reasons, GitHub Actions builds triggered by Pull Request events run under the security context of the pull request fork repository (the PR author's repository). Security is the main reason why PR builds should be kept to run such that they are triggered by the PR event. It would be useful to have a manual approval step to run a PR build in GitHub Actions. There was a discussion on Twitter about this kind of feature request yesterday: https://twitter.com/bsideup/status/1372554960420941830 Perhaps a solution evolves for this over time so that PR builds can be triggered securely upon request. Currently that doesn't seem to be possible with GitHub Actions. The discussion mentioned "slash command dispatch" action, https://github.com/peter-evans/slash-command-dispatch, but I don't think that there is a solution for the security issues. One of the main security issues would be a cache poisoning attack. A PR build that is run in the context of the main repository could "poison" the GitHub Actions Cache and use it to inject trojans. -Lari On Fri, Mar 19, 2021 at 7:58 PM Enrico Olivelli <eolive...@gmail.com> wrote: > 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 > > >
