Il giorno ven 19 mar 2021 alle ore 20:09 Lari Hotari <l...@hotari.net> ha scritto: > > 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.
Here it is https://github.com/apache/pulsar/issues/9982 Thanks Enrico > > > 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 > > > > >
