NightOwl888 commented on PR #709: URL: https://github.com/apache/lucenenet/pull/709#issuecomment-1304477381
So, ran into a snag: Apache doesn't allow scans to be run from a PR from a fork. And only Apache committers are allowed to push to `apache/lucenenet` which is a rare thing, anyway. That basically makes the PR scan useless. I have looked at several of the projects at: https://sonarcloud.io/organizations/apache/projects, and indeed couldn't find a single one that has a PR count greater than 0. I took a look into the repositories, and some of them have switched to using CodeQL instead. I suspect this is because there is a `github/codeql/action/analyze` plugin officially released by GitHub, and therefore it is in Apache's approved list. Example: https://github.com/apache/commons-compress/blob/910bfc05f7ca693f87166ca376980107d13fa2b5/.github/workflows/codeql-analysis.yml That being said, I am not sure how much mileage we will get out of this in PRs, anyway. 1. This is going to make the checks for the PR run even longer. 2. Diverging from the original Java code is discouraged, so PRs with large amounts of code changes are not likely to be accepted, anyway. A scan for code changes just isn't all that useful until we start working on the upgrade. 3. We don't want existing problems showing up in scans for minor bug fixes or documentation changes that are contributed. If we instead set this up as a nightly scan: 1. We can take as much time as needed to do the scan. 2. When the results are in, we can have an email sent to [the build mailing list](https://lucenenet.apache.org/contributing/mailing-lists.html#builds-builds) with a link to the scan report. 3. We can set up a code coverage report. I found a doc that says there is no time limit for running Apache agents. Although, they only have 180 agents across 1200 projects, hanging onto 1 of them for 3-4 hours probably isn't that big of a deal. https://infra.apache.org/github-actions-secrets.html > **NOTE:**: We already have a [nightly build set up on Azure DevOps](https://dev.azure.com/lucene-net/Lucene.NET/_build?definitionId=4), but there is a 1 hour time limit on each agent, so it is less than ideal for doing something like this. It occasionally fails because the original Lucene setup took about 4 hours and we had to cut down the number of iterations to get it under 1 hour. But there are still some slow random choices that it makes that put it over 1 hour - the test framework wasn't designed with a time limit in mind. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
