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 >
