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 <lh...@apache.org> on 2022/09/27 16:01:41 UTC
Pulsar CI slowness continues
Hi all,
GitHub Actions isn't providing sufficient resources for apache/pulsar repository at the moment and this causes the build queue to increase.
We are already using the solution where most of the builds are run in the context of the forked repository. This remains currently the only practical way to get CI feedback and it has been working well.
Here are the Pulsar CI instructions for running Pulsar CI tests in your own fork of apache/pulsar after you have created a PR to apache/pulsar. The benefit of this solution is that your own fork has independent quota from apache/pulsar and this is usually not congested. All Apache projects share the same quota on GitHub and that's one reason why apache/pulsar is suffering from insufficient GitHub Actions resources.
1. Go to your fork of apache/pulsar in the GitHub UI and ensure that your master branch is up to date with https://github.com/apache/pulsar. Sync your fork if it's behind.
- https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork
2. Open a pull request to your own fork for the pull request branch. If the apache/pulsar CI jobs run, it will provide a link which can be used to create the pull request conveniently. This link is in the build failure message.
3. Edit the description of the upstream pull request made to apache/pulsar repository and add the link to the PR that you opened to your own fork so that the reviewer can verify that tests pass in your own fork.
4. Ensure that tests pass in your own fork. Your own fork will be used to run the tests during the PR review and any changes made during the review. You as a PR author are responsible for following up on test failures.
- Please report any flaky tests as new issues at https://github.com/apache/pulsar/issues after checking that the flaky test isn't already reported.
5. When the PR is approved, it will be possible to restart the Pulsar CI workflow within apache/pulsar repository by adding a comment "/pulsarbot rerun-failure-checks" to the PR.
An alternative for the PR approval is to add a ready-to-test label to the PR. This can be done by Apache Pulsar committers.
6. When tests pass on the apache/pulsar side, the PR can be merged by a Apache Pulsar Committer.
At the moment, there's a long build queue and it takes very long to get any builds started for apache/pulsar builds. If this situation continues, we might have to considers an approach where we drop the "required checks" requirement for apache/pulsar and solely trust on the results of test runs made in the forked repostories. It's not an optimal solution since it's possible that some PRs get accidentially merged when the test status in the fork isn't properly validated by the committer who merges the PR. This solution would allow us to keep on processing PRs while there's a resource shortage in GitHub Actions for the Apache organization account.
I have an issue opened to GitHub support, but the support engineer hasn't provided sufficient answer and resolution yet. I don't have high hopes about it being helpful since GitHub support hasn't been very responsive and supportive in resolving the matter.
Best Regards,
-Lari
Re: Pulsar CI slowness continues
Posted by Enrico Olivelli <eo...@gmail.com>.
Il giorno mer 28 set 2022 alle ore 07:50 Lari Hotari
<lh...@apache.org> ha scritto:
>
> There was an incident with GitHub Actions yesterday, https://www.githubstatus.com/incidents/nbhb2lxyh9bb .
>
> It looks like Pulsar CI is back in action today.
>
> I finally got a helpful response from GitHub Support. They are now aware of the issues and looking for ways how to improve the situation for Apache organization projects.
Great news !
Enrico
>
>
> -Lari
>
> On 2022/09/27 16:01:41 Lari Hotari wrote:
> > Hi all,
> >
> > GitHub Actions isn't providing sufficient resources for apache/pulsar repository at the moment and this causes the build queue to increase.
> >
> > We are already using the solution where most of the builds are run in the context of the forked repository. This remains currently the only practical way to get CI feedback and it has been working well.
> >
> > Here are the Pulsar CI instructions for running Pulsar CI tests in your own fork of apache/pulsar after you have created a PR to apache/pulsar. The benefit of this solution is that your own fork has independent quota from apache/pulsar and this is usually not congested. All Apache projects share the same quota on GitHub and that's one reason why apache/pulsar is suffering from insufficient GitHub Actions resources.
> >
> > 1. Go to your fork of apache/pulsar in the GitHub UI and ensure that your master branch is up to date with https://github.com/apache/pulsar. Sync your fork if it's behind.
> > - https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork
> > 2. Open a pull request to your own fork for the pull request branch. If the apache/pulsar CI jobs run, it will provide a link which can be used to create the pull request conveniently. This link is in the build failure message.
> > 3. Edit the description of the upstream pull request made to apache/pulsar repository and add the link to the PR that you opened to your own fork so that the reviewer can verify that tests pass in your own fork.
> > 4. Ensure that tests pass in your own fork. Your own fork will be used to run the tests during the PR review and any changes made during the review. You as a PR author are responsible for following up on test failures.
> > - Please report any flaky tests as new issues at https://github.com/apache/pulsar/issues after checking that the flaky test isn't already reported.
> > 5. When the PR is approved, it will be possible to restart the Pulsar CI workflow within apache/pulsar repository by adding a comment "/pulsarbot rerun-failure-checks" to the PR.
> > An alternative for the PR approval is to add a ready-to-test label to the PR. This can be done by Apache Pulsar committers.
> > 6. When tests pass on the apache/pulsar side, the PR can be merged by a Apache Pulsar Committer.
> >
> > At the moment, there's a long build queue and it takes very long to get any builds started for apache/pulsar builds. If this situation continues, we might have to considers an approach where we drop the "required checks" requirement for apache/pulsar and solely trust on the results of test runs made in the forked repostories. It's not an optimal solution since it's possible that some PRs get accidentially merged when the test status in the fork isn't properly validated by the committer who merges the PR. This solution would allow us to keep on processing PRs while there's a resource shortage in GitHub Actions for the Apache organization account.
> > I have an issue opened to GitHub support, but the support engineer hasn't provided sufficient answer and resolution yet. I don't have high hopes about it being helpful since GitHub support hasn't been very responsive and supportive in resolving the matter.
> >
> > Best Regards,
> >
> > -Lari
> >
Re: Pulsar CI slowness continues
Posted by Lari Hotari <lh...@apache.org>.
There was an incident with GitHub Actions yesterday, https://www.githubstatus.com/incidents/nbhb2lxyh9bb .
It looks like Pulsar CI is back in action today.
I finally got a helpful response from GitHub Support. They are now aware of the issues and looking for ways how to improve the situation for Apache organization projects.
-Lari
On 2022/09/27 16:01:41 Lari Hotari wrote:
> Hi all,
>
> GitHub Actions isn't providing sufficient resources for apache/pulsar repository at the moment and this causes the build queue to increase.
>
> We are already using the solution where most of the builds are run in the context of the forked repository. This remains currently the only practical way to get CI feedback and it has been working well.
>
> Here are the Pulsar CI instructions for running Pulsar CI tests in your own fork of apache/pulsar after you have created a PR to apache/pulsar. The benefit of this solution is that your own fork has independent quota from apache/pulsar and this is usually not congested. All Apache projects share the same quota on GitHub and that's one reason why apache/pulsar is suffering from insufficient GitHub Actions resources.
>
> 1. Go to your fork of apache/pulsar in the GitHub UI and ensure that your master branch is up to date with https://github.com/apache/pulsar. Sync your fork if it's behind.
> - https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork
> 2. Open a pull request to your own fork for the pull request branch. If the apache/pulsar CI jobs run, it will provide a link which can be used to create the pull request conveniently. This link is in the build failure message.
> 3. Edit the description of the upstream pull request made to apache/pulsar repository and add the link to the PR that you opened to your own fork so that the reviewer can verify that tests pass in your own fork.
> 4. Ensure that tests pass in your own fork. Your own fork will be used to run the tests during the PR review and any changes made during the review. You as a PR author are responsible for following up on test failures.
> - Please report any flaky tests as new issues at https://github.com/apache/pulsar/issues after checking that the flaky test isn't already reported.
> 5. When the PR is approved, it will be possible to restart the Pulsar CI workflow within apache/pulsar repository by adding a comment "/pulsarbot rerun-failure-checks" to the PR.
> An alternative for the PR approval is to add a ready-to-test label to the PR. This can be done by Apache Pulsar committers.
> 6. When tests pass on the apache/pulsar side, the PR can be merged by a Apache Pulsar Committer.
>
> At the moment, there's a long build queue and it takes very long to get any builds started for apache/pulsar builds. If this situation continues, we might have to considers an approach where we drop the "required checks" requirement for apache/pulsar and solely trust on the results of test runs made in the forked repostories. It's not an optimal solution since it's possible that some PRs get accidentially merged when the test status in the fork isn't properly validated by the committer who merges the PR. This solution would allow us to keep on processing PRs while there's a resource shortage in GitHub Actions for the Apache organization account.
> I have an issue opened to GitHub support, but the support engineer hasn't provided sufficient answer and resolution yet. I don't have high hopes about it being helpful since GitHub support hasn't been very responsive and supportive in resolving the matter.
>
> Best Regards,
>
> -Lari
>