You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pulsar.apache.org by Lari Hotari <la...@sagire.fi> on 2021/03/19 12:37:04 UTC
Setting up personal Pulsar CI for reducing load on apache/pulsar CI
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
Re: Setting up personal Pulsar CI for reducing load on apache/pulsar CI
Posted by Lari Hotari <La...@hotari.net>.
Good idea. Let's see if this "personal CI" solution turns out to be useful.
-Lari
On Fri, Mar 19, 2021 at 7:21 PM Jonathan Ellis <jb...@gmail.com> wrote:
> 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 <la...@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
>
Re: Setting up personal Pulsar CI for reducing load on apache/pulsar CI
Posted by Lari Hotari <La...@hotari.net>.
On Fri, Mar 19, 2021 at 10:52 PM Enrico Olivelli <eo...@gmail.com>
wrote:
> Here it is
> https://github.com/apache/pulsar/issues/9982
>
>
Here's a PR to address pull requests in draft status:
https://github.com/apache/pulsar/pull/9994
Unfortunately, it's not possible to disable builds completely for PRs in
draft status. The solution in the PR #9994 will fail-fast builds when the
PR is in draft status. That should help achieve the goal of reducing
resource consumption for PRs that are in draft status.
The suggested solution in the GitHub community discussion seems to have the
downside that a PR would be mergeable after a PR which is in draft status
gets changed to "ready for review". This was reported in one of the
comments:
https://github.community/t/dont-run-actions-on-draft-pull-requests/16817/8
.
"When the PR is switched from “draft” to “ready” the CI does not run again
and the check is still marked as successful, so a user is able to merge
the PR without having the check actually pass. "
This problem might have been addressed with the "ready-for-review" event
type filter. Since there isn't a guarantee about that, PR #9994 contains
the fail-fast solutions which won't have the issue that PRs pass the checks
accidentally after a draft PR is put to ready-for-review and someone
immediately merges the PR.
-Lari
Re: Setting up personal Pulsar CI for reducing load on apache/pulsar CI
Posted by Enrico Olivelli <eo...@gmail.com>.
Il giorno ven 19 mar 2021 alle ore 20:09 Lari Hotari <La...@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 <eo...@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 <jb...@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 <la...@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
> > >
> >
Re: Setting up personal Pulsar CI for reducing load on apache/pulsar CI
Posted by Lari Hotari <La...@hotari.net>.
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 <eo...@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 <jb...@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 <la...@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
> >
>
Re: Setting up personal Pulsar CI for reducing load on apache/pulsar CI
Posted by Enrico Olivelli <eo...@gmail.com>.
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 <jb...@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 <la...@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
>
Re: Setting up personal Pulsar CI for reducing load on apache/pulsar CI
Posted by Jonathan Ellis <jb...@gmail.com>.
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 <la...@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