Il giorno mer 28 set 2022 alle ore 07:50 Lari Hotari <lhot...@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 > >
