config: migrate all openjdk repositories in projects-to-test-on to github mirrors(#524)

[nrmancuso]

Issue #524: migrate all openjdk repositories in projects-to-test-on.properties to github mirrors

Openjdk 16 project has been added, and all others replaced.

[nrmancuso]

Before I mark this ready for review, we need to resolve two items:

• open an issue for openjdk11-with-checks-nonjavadoc-error if we decide to do that

• successful dummy Checkstyle PR using this file with "github, generate report"

[nrmancuso]

Regression on Openjdk10 and Openjdk9 is still suffering from a similar failure JXR failure that Openjdk11 and Openjdk 14. I am going to investigate what the differences between the mercurial and git repos are, since we had no problems with Openjdk9 in the past.

Edit:

➜  jdk-tester diff -q jdk openjdk-jdk9u 
Only in openjdk-jdk9u: ADDITIONAL_LICENSE_INFO
Only in openjdk-jdk9u: common
Only in openjdk-jdk9u: configure
Only in openjdk-jdk9u: corba
Only in openjdk-jdk9u: .git
Only in jdk: .hg
Only in jdk: .hgignore
Only in jdk: .hgtags
Only in openjdk-jdk9u: hotspot
Only in openjdk-jdk9u: jaxp
Only in openjdk-jdk9u: jaxws
Common subdirectories: jdk/.jcheck and openjdk-jdk9u/.jcheck
Only in openjdk-jdk9u: jdk
Only in openjdk-jdk9u: langtools
Common subdirectories: jdk/make and openjdk-jdk9u/make
Only in openjdk-jdk9u: Makefile
Only in openjdk-jdk9u: nashorn
Only in openjdk-jdk9u: README
Only in openjdk-jdk9u: README.md
Only in jdk: src
Common subdirectories: jdk/test and openjdk-jdk9u/test

jdk == mercurial repo, openjdk-jdk9u == git repo

As in the case of Openjdk11 and Openjdk14, it is likely that langtools/ contains files that create a problem for JXR. I think it would be good to remove JXR before proceeding with this issue. @romani @rnveach thoughts?

[romani]

Should we create a CI execution similar to openjdk14-with-checks-nonjavadoc-error for openjdk11?

No need. Let's keep single but well filtered.

Before I mark this ready for review, we need to resolve two items:

Please update

I think it would be good to remove JXR before proceeding with this issue.

Please proceed to remove

[rnveach]

@nmancus1 ping?

[nrmancuso]

@rnveach Sorry, I have finals this week and next, I was putting the removal of jxr and maven-checkstyle-plugin off until the end of next week.

[nrmancuso]

@rnveach Commit 92be3fb is checked out as a branch per checkstyle/checkstyle#9121 (comment), then built with mvn clean install -Pno-validations. Local maven repo contains the correct snapshot. The pom.xml in checkstyle-tester points to this version.

launch.groovy:
Left is on the master branch of the contribution repo, and right is the cleanup-projects branch (my changes from #527):
. So, launch.groovy does not produce a crosslinked checkstyle report after removing the jxr plugin.

[rnveach]

@nmancus1 please split this PR between JXR removal and migrating mirrors.
#530 and #524 .

If you agree with plan at checkstyle/checkstyle#9121 (comment) , gutting launch of HTML files is fine with me.

[rnveach]

Blocked by #530 ( see #531 (comment) )

[rnveach]

@nmancus1 Something happened with the PR, it contains the previous PR's changes too.

Also please tie this to #524 in commit message.

[nrmancuso]

Something happened with the PR, it contains the previous PR's changes too.
Also please tie this to #524 in commit message.

Done, I thought I had fixed it before anyone noticed :)

[rnveach]

Quick question..

[rnveach]

@nmancus1 It looks like connected issue is resolved. Maybe we could finish this now?

[nrmancuso]

PR to demo new repo at checkstyle/checkstyle#10911

[nrmancuso]

@rnveach I have not been able to reproduce failure at checkstyle/checkstyle#10911 locally at all. The way I see it, we can proceed a few different ways here:

1. Close this PR, leave issue for "someday"
2. Exclude the offending file. This means that we must allow exclusions in Checkstyle diff report generation.
3. Create a "Checkstyle" fork of the repo with offending file removed, just for diff report generation.

I would like to do (2). Please share your thoughts.

[rnveach]

Is this the only file with an issue or are there more?

[nrmancuso]

Is this the only file with an issue or are there more?

I think the only way to determine this definitively would be to allow exclusions in diff report generation and try it out in GitHub action CI. Since I cannot reproduce this failure locally, I can't guarantee that there isn't more files like this.

But, after thinking on this for awhile, we should really allow exclusions anyway, so that we can run regression in GitHub actions on the newest or at least more current jdk. We still really don't have any projects in the projects file that extensively use newer syntax.

[nrmancuso]

@rnveach to be clear, should I send a PR to main Checkstyle repo to allow exclusions in diff report generation?

[rnveach]

Is main repo doing "launch" or diff?

The only way main repo can exclude files is to delete them after the cloning and even still I think the diff-side groovy script controls everything. It was not built for excluding files when doing regression. I was looking to understand how many files we would need to exclude to determine how we would handle this list, if it is just 1 file or many.

[nrmancuso]

Is main repo doing "launch" or diff?

launch.groovy does not exist any longer.

The only way main repo can exclude files is to delete them after the cloning and even still I think the diff-side groovy script controls everything.

Support for exclusions was added to diff.groovy in #529

I was looking to understand how many files we would need to exclude to determine how we would handle this list, if it is just 1 file or many.

It would be best to:

1. Allow exclusions in diff_report.yml in main repo
2. Run diff.groovy on newer openjdk
3. Add exclusions as needed to projects file until diff report generation passes

Otherwise, there is no way to know exactly which files will fail in github actions servers. Just because I can complete this task locally does not mean that it will succeed on github actions, the servers used are not spectacular: https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners

[rnveach]

Support for exclusions was added to diff.groovy in #529

Except that support only exists for the launch side of things, not for difference reporting. Even if launch is gone, is functionality is in diff and still separate.

Since this is projects-to-test-on this means we are talking about the diff side so there is no exclusion functionality except if added to the config.

Just because I can complete this task locally does not mean that it will succeed on github actions, the servers used are not spectacular:

Again, finishing locally will atleast tell us if we need to support a small list or a large list. If its a large list, we can't use launch's method of exclusion as it will become immense.

Please create new issue for this.

[rnveach]

Use the property allowExcludes.
#580 (comment)

[nrmancuso]

Again, finishing locally will atleast tell us if we need to support a small list or a large list.

If we just use openjdk16 (which we should), we can look to https://github.com/checkstyle/checkstyle/blob/a7a3f7ac2766fddcc00b752f91e8c31cafdd61e6/.ci/openjdk16-excluded.files for the exact list of files to use

[rnveach]

Yes, it makes more sense we combine this into 1 effort.

[nrmancuso]

Proof of successful parsing of new openjdk project here: https://checkstyle-diff-reports.s3.us-east-2.amazonaws.com/10a2890_2021173033/reports/diff/index.html

[rnveach]

@romani I feel we need to discuss functionality to allow exclude list to be in a file and not rely on this gigantic one line list of 13k characters. This is not the way to go, especially when we are trying to limit our own files in our repo to 100 characters.
I will create issue on this to not impede this PR.

[rnveach]

#588

[romani]

sure, this 10 years old quick-hack over idea how to do regression testing surprisingly still in service, but it is clear that there is bunch of need to make it different.

[romani]

ok to merge meanwhile it is upleasantly long line