You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by GitBox <gi...@apache.org> on 2022/05/10 22:37:03 UTC

[GitHub] [pulsar] heesung-sn opened a new pull request, #15535: gi[improve][doc] added instructions about how to run ci from fork

heesung-sn opened a new pull request, #15535:
URL: https://github.com/apache/pulsar/pull/15535

   <!--
   ### Contribution Checklist
     
     - PR title format should be *[type][component] summary*. For details, see *[Guideline - Pulsar PR Naming Convention](https://docs.google.com/document/d/1d8Pw6ZbWk-_pCKdOmdvx9rnhPiyuxwq60_TrD68d7BA/edit#heading=h.trs9rsex3xom)*. 
   
     - Fill out the template below to describe the changes contributed by the pull request. That will give reviewers the context they need to do the review.
     
     - Each pull request should address only one issue, not mix up code from multiple issues.
     
     - Each commit in the pull request has a meaningful commit message
   
     - Once all items of the checklist are addressed, remove the above text and this checklist, leaving only the filled out template below.
   
   **(The sections below can be removed for hotfixes of typos)**
   -->
   
   ### Motivation
   As commented [here](https://github.com/apache/pulsar/pull/15264#issuecomment-1113076698), moving this instruction, `how to run Pulsar CI from fork`, to the contribution page in order to make it more accessible for new contributors.
   
   ### Modifications
   
   Added instructions about how to run Pulsar CI from forked github repositories in the contribution page. 
   
   ### Verifying this change
   
   This change is a trivial rework / code cleanup without any test coverage.
   
   ### Does this pull request potentially affect one of the following parts:
   
   *If `yes` was chosen, please highlight the changes*
   
     - Dependencies (does it add or upgrade a dependency): (yes / **no**)
     - The public API: (yes / **no**)
     - The schema: (yes / **no** / don't know)
     - The default values of configurations: (yes / **no**)
     - The wire protocol: (yes / **no**)
     - The rest endpoints: (yes / **no**)
     - The admin cli options: (yes / **no**)
     - Anything that affects deployment: (yes / **no** / don't know)
   
   ### Documentation
   
   Check the box below or label this PR directly.
   
   Need to update docs? 
   
   - [ ] `doc-required` 
   (Your PR needs to update docs and you will update later)
     
   - [ ] `no-need-doc` 
   (Please explain why)
     
   - [x] `doc` 
   (Your PR contains doc changes)
   
   - [ ] `doc-added`
   (Docs have been already added)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [pulsar] heesung-sn commented on a diff in pull request #15535: [improve][doc] added instructions about how to run ci from fork

Posted by GitBox <gi...@apache.org>.
heesung-sn commented on code in PR #15535:
URL: https://github.com/apache/pulsar/pull/15535#discussion_r870453073


##########
site2/website/contributing.md:
##########
@@ -149,6 +149,97 @@ Then you can push your local, committed changes to your (forked) repository on G
 
 All code should have appropriate unit testing coverage. New code should have new tests in the same contribution. Bug fixes should include a regression test to prevent the issue from reoccurring.
 
+
+### CI Testing in your Fork
+
+The following is copied from the
+[thread](https://lists.apache.org/thread/1ofdbd9j1hhj4c0rw3o7vv8y6rbsxrp0) and [#15385](https://github.com/apache/pulsar/pull/15385).
+
+
+#### Each PR triggers many CI Jobs
+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.
+
+#### Run CI from Fork
+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.
+
+#### Stay in-sync with apache/pulsar:master
+
+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

Review Comment:
   updated.



##########
site2/website/contributing.md:
##########
@@ -149,6 +149,97 @@ Then you can push your local, committed changes to your (forked) repository on G
 
 All code should have appropriate unit testing coverage. New code should have new tests in the same contribution. Bug fixes should include a regression test to prevent the issue from reoccurring.
 
+
+### CI Testing in your Fork
+
+The following is copied from the
+[thread](https://lists.apache.org/thread/1ofdbd9j1hhj4c0rw3o7vv8y6rbsxrp0) and [#15385](https://github.com/apache/pulsar/pull/15385).
+
+
+#### Each PR triggers many CI Jobs
+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.
+
+#### Run CI from Fork
+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.

Review Comment:
   updated.



##########
site2/website/contributing.md:
##########
@@ -149,6 +149,97 @@ Then you can push your local, committed changes to your (forked) repository on G
 
 All code should have appropriate unit testing coverage. New code should have new tests in the same contribution. Bug fixes should include a regression test to prevent the issue from reoccurring.
 
+
+### CI Testing in your Fork
+
+The following is copied from the
+[thread](https://lists.apache.org/thread/1ofdbd9j1hhj4c0rw3o7vv8y6rbsxrp0) and [#15385](https://github.com/apache/pulsar/pull/15385).
+
+
+#### Each PR triggers many CI Jobs
+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.
+
+#### Run CI from Fork
+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.
+
+#### Stay in-sync with apache/pulsar:master
+
+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
+```
+
+#### ssh to CI Jobs
+
+The additional benefit of the "Personal CI" is that you get ssh access to the build VMs when the build is running.
+That is handled by this logic in the pulsar-ci.yaml GitHub Actions workflow file:
+`pulsar/.github/workflows/pulsar-ci.yaml`
+
+
+```
+- name: Setup ssh access to build runner VM
+  # ssh access is enabled for builds in own forks
+  if: ${{ github.repository != 'apache/pulsar' && needs.changed_files_job.outputs.docs_only != 'true' }}
+  uses: ./.github/actions/ssh-access
+  with:
+  limit-access-to-actor: true
+```
+and inline composite action [implementation](https://github.com/apache/pulsar/blob/master/.github/actions/ssh-access/action.yml).
+The ssh acccess is secured with the ssh key registered in Github.
+For example, your public keys are https://github.com/horizonzy.keys.
+You will first have to register a ssh public key in GitHub for that to work.

Review Comment:
   updated.



##########
site2/website/contributing.md:
##########
@@ -149,6 +149,97 @@ Then you can push your local, committed changes to your (forked) repository on G
 
 All code should have appropriate unit testing coverage. New code should have new tests in the same contribution. Bug fixes should include a regression test to prevent the issue from reoccurring.
 
+
+### CI Testing in your Fork
+
+The following is copied from the
+[thread](https://lists.apache.org/thread/1ofdbd9j1hhj4c0rw3o7vv8y6rbsxrp0) and [#15385](https://github.com/apache/pulsar/pull/15385).
+
+
+#### Each PR triggers many CI Jobs
+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.
+
+#### Run CI from Fork
+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.
+
+#### Stay in-sync with apache/pulsar:master
+
+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
+```
+
+#### ssh to CI Jobs
+
+The additional benefit of the "Personal CI" is that you get ssh access to the build VMs when the build is running.
+That is handled by this logic in the pulsar-ci.yaml GitHub Actions workflow file:
+`pulsar/.github/workflows/pulsar-ci.yaml`
+
+
+```
+- name: Setup ssh access to build runner VM
+  # ssh access is enabled for builds in own forks
+  if: ${{ github.repository != 'apache/pulsar' && needs.changed_files_job.outputs.docs_only != 'true' }}
+  uses: ./.github/actions/ssh-access
+  with:
+  limit-access-to-actor: true
+```
+and inline composite action [implementation](https://github.com/apache/pulsar/blob/master/.github/actions/ssh-access/action.yml).
+The ssh acccess is secured with the ssh key registered in Github.

Review Comment:
   updated.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [pulsar] momo-jun commented on a diff in pull request #15535: [improve][doc] added instructions about how to run ci from fork

Posted by GitBox <gi...@apache.org>.
momo-jun commented on code in PR #15535:
URL: https://github.com/apache/pulsar/pull/15535#discussion_r869803235


##########
site2/website/contributing.md:
##########
@@ -149,6 +149,97 @@ Then you can push your local, committed changes to your (forked) repository on G
 
 All code should have appropriate unit testing coverage. New code should have new tests in the same contribution. Bug fixes should include a regression test to prevent the issue from reoccurring.
 
+
+### CI Testing in your Fork
+
+The following is copied from the
+[thread](https://lists.apache.org/thread/1ofdbd9j1hhj4c0rw3o7vv8y6rbsxrp0) and [#15385](https://github.com/apache/pulsar/pull/15385).
+
+
+#### Each PR triggers many CI Jobs
+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.
+
+#### Run CI from Fork
+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.

Review Comment:
   ```suggestion
   your own fork as both the forked repository and head repository.
   ```



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [pulsar] heesung-sn commented on pull request #15535: [improve][doc] added instructions about how to run ci from fork

Posted by GitBox <gi...@apache.org>.
heesung-sn commented on PR #15535:
URL: https://github.com/apache/pulsar/pull/15535#issuecomment-1154232337

   > @heesung-sn @Anonymitaet It looks like these instructions have been dropped and aren't on the new website. Would it be possible to get the content to the new website too?
   
   Raised a PR to the new website repo, https://github.com/apache/pulsar-site/pull/111/ 
   @Anonymitaet could you check this by any chance?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [pulsar] momo-jun commented on a diff in pull request #15535: [improve][doc] added instructions about how to run ci from fork

Posted by GitBox <gi...@apache.org>.
momo-jun commented on code in PR #15535:
URL: https://github.com/apache/pulsar/pull/15535#discussion_r869802755


##########
site2/website/contributing.md:
##########
@@ -149,6 +149,97 @@ Then you can push your local, committed changes to your (forked) repository on G
 
 All code should have appropriate unit testing coverage. New code should have new tests in the same contribution. Bug fixes should include a regression test to prevent the issue from reoccurring.
 
+
+### CI Testing in your Fork
+
+The following is copied from the
+[thread](https://lists.apache.org/thread/1ofdbd9j1hhj4c0rw3o7vv8y6rbsxrp0) and [#15385](https://github.com/apache/pulsar/pull/15385).
+
+
+#### Each PR triggers many CI Jobs
+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.
+
+#### Run CI from Fork
+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.
+
+#### Stay in-sync with apache/pulsar:master
+
+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
+```
+
+#### ssh to CI Jobs
+
+The additional benefit of the "Personal CI" is that you get ssh access to the build VMs when the build is running.
+That is handled by this logic in the pulsar-ci.yaml GitHub Actions workflow file:
+`pulsar/.github/workflows/pulsar-ci.yaml`
+
+
+```
+- name: Setup ssh access to build runner VM
+  # ssh access is enabled for builds in own forks
+  if: ${{ github.repository != 'apache/pulsar' && needs.changed_files_job.outputs.docs_only != 'true' }}
+  uses: ./.github/actions/ssh-access
+  with:
+  limit-access-to-actor: true
+```
+and inline composite action [implementation](https://github.com/apache/pulsar/blob/master/.github/actions/ssh-access/action.yml).
+The ssh acccess is secured with the ssh key registered in Github.

Review Comment:
   ```suggestion
   The ssh access is secured with the ssh key registered in GitHub.
   ```



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [pulsar] lhotari commented on pull request #15535: [improve][doc] added instructions about how to run ci from fork

Posted by GitBox <gi...@apache.org>.
lhotari commented on PR #15535:
URL: https://github.com/apache/pulsar/pull/15535#issuecomment-1153989971

   @heesung-sn @Anonymitaet It looks like these instructions have been dropped and aren't on the new website. Would it be possible to get the content to the new website too?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [pulsar] heesung-sn commented on pull request #15535: [improve][doc] added instructions about how to run ci from fork

Posted by GitBox <gi...@apache.org>.
heesung-sn commented on PR #15535:
URL: https://github.com/apache/pulsar/pull/15535#issuecomment-1123920226

   Thank you for checking this PR. I resolved the above comments.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [pulsar] momo-jun commented on a diff in pull request #15535: [improve][doc] added instructions about how to run ci from fork

Posted by GitBox <gi...@apache.org>.
momo-jun commented on code in PR #15535:
URL: https://github.com/apache/pulsar/pull/15535#discussion_r869802877


##########
site2/website/contributing.md:
##########
@@ -149,6 +149,97 @@ Then you can push your local, committed changes to your (forked) repository on G
 
 All code should have appropriate unit testing coverage. New code should have new tests in the same contribution. Bug fixes should include a regression test to prevent the issue from reoccurring.
 
+
+### CI Testing in your Fork
+
+The following is copied from the
+[thread](https://lists.apache.org/thread/1ofdbd9j1hhj4c0rw3o7vv8y6rbsxrp0) and [#15385](https://github.com/apache/pulsar/pull/15385).
+
+
+#### Each PR triggers many CI Jobs
+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.
+
+#### Run CI from Fork
+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.
+
+#### Stay in-sync with apache/pulsar:master
+
+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
+```
+
+#### ssh to CI Jobs
+
+The additional benefit of the "Personal CI" is that you get ssh access to the build VMs when the build is running.
+That is handled by this logic in the pulsar-ci.yaml GitHub Actions workflow file:
+`pulsar/.github/workflows/pulsar-ci.yaml`
+
+
+```
+- name: Setup ssh access to build runner VM
+  # ssh access is enabled for builds in own forks
+  if: ${{ github.repository != 'apache/pulsar' && needs.changed_files_job.outputs.docs_only != 'true' }}
+  uses: ./.github/actions/ssh-access
+  with:
+  limit-access-to-actor: true
+```
+and inline composite action [implementation](https://github.com/apache/pulsar/blob/master/.github/actions/ssh-access/action.yml).
+The ssh acccess is secured with the ssh key registered in Github.
+For example, your public keys are https://github.com/horizonzy.keys.
+You will first have to register a ssh public key in GitHub for that to work.

Review Comment:
   ```suggestion
   You will first have to register an ssh public key in GitHub for that to work.
   ```



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [pulsar] Anonymitaet merged pull request #15535: [improve][doc] added instructions about how to run ci from fork

Posted by GitBox <gi...@apache.org>.
Anonymitaet merged PR #15535:
URL: https://github.com/apache/pulsar/pull/15535


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [pulsar] Anonymitaet commented on pull request #15535: [improve][doc] added instructions about how to run ci from fork

Posted by GitBox <gi...@apache.org>.
Anonymitaet commented on PR #15535:
URL: https://github.com/apache/pulsar/pull/15535#issuecomment-1154811152

   > > @heesung-sn @Anonymitaet It looks like these instructions have been dropped and aren't on the new website. Would it be possible to get the content to the new website too?
   > 
   > Raised a PR to the new website repo, [apache/pulsar-site#111](https://github.com/apache/pulsar-site/pull/111) @Anonymitaet could you check this by any chance?
   
   sure, commented in your new PR.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [pulsar] momo-jun commented on a diff in pull request #15535: [improve][doc] added instructions about how to run ci from fork

Posted by GitBox <gi...@apache.org>.
momo-jun commented on code in PR #15535:
URL: https://github.com/apache/pulsar/pull/15535#discussion_r869804817


##########
site2/website/contributing.md:
##########
@@ -149,6 +149,97 @@ Then you can push your local, committed changes to your (forked) repository on G
 
 All code should have appropriate unit testing coverage. New code should have new tests in the same contribution. Bug fixes should include a regression test to prevent the issue from reoccurring.
 
+
+### CI Testing in your Fork
+
+The following is copied from the
+[thread](https://lists.apache.org/thread/1ofdbd9j1hhj4c0rw3o7vv8y6rbsxrp0) and [#15385](https://github.com/apache/pulsar/pull/15385).
+
+
+#### Each PR triggers many CI Jobs
+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.
+
+#### Run CI from Fork
+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.
+
+#### Stay in-sync with apache/pulsar:master
+
+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

Review Comment:
   ```suggestion
   Let's say you have git remotes called "upstream" for apache/pulsar and
   ```



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [pulsar] Anonymitaet commented on a diff in pull request #15535: [improve][doc] added instructions about how to run ci from fork

Posted by GitBox <gi...@apache.org>.
Anonymitaet commented on code in PR #15535:
URL: https://github.com/apache/pulsar/pull/15535#discussion_r870152125


##########
site2/website/contributing.md:
##########
@@ -149,6 +149,97 @@ Then you can push your local, committed changes to your (forked) repository on G
 
 All code should have appropriate unit testing coverage. New code should have new tests in the same contribution. Bug fixes should include a regression test to prevent the issue from reoccurring.
 
+
+### CI Testing in your Fork
+
+The following is copied from the
+[thread](https://lists.apache.org/thread/1ofdbd9j1hhj4c0rw3o7vv8y6rbsxrp0) and [#15385](https://github.com/apache/pulsar/pull/15385).
+
+
+#### Each PR triggers many CI Jobs
+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.
+
+#### Run CI from Fork
+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.
+
+#### Stay in-sync with apache/pulsar:master
+
+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
+```
+
+#### ssh to CI Jobs
+
+The additional benefit of the "Personal CI" is that you get ssh access to the build VMs when the build is running.
+That is handled by this logic in the pulsar-ci.yaml GitHub Actions workflow file:
+`pulsar/.github/workflows/pulsar-ci.yaml`
+
+
+```
+- name: Setup ssh access to build runner VM
+  # ssh access is enabled for builds in own forks
+  if: ${{ github.repository != 'apache/pulsar' && needs.changed_files_job.outputs.docs_only != 'true' }}
+  uses: ./.github/actions/ssh-access
+  with:
+  limit-access-to-actor: true
+```
+and inline composite action [implementation](https://github.com/apache/pulsar/blob/master/.github/actions/ssh-access/action.yml).
+The ssh acccess is secured with the ssh key registered in Github.

Review Comment:
   +1
   
   and "SSH, SSH key", please pay attention to the capitalization for proper nouns



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org