minor: add openjdk21 and remove openjdk17 from projects file for report generation#878
Conversation
please help with this I don't understand the failure. I need this update to use the default list. We should have openjdk21 in the default projects now. |
|
Provide us a link to what is being executed before this diff.groovy call so we can see the context of the job. |
|
I meant the source code. You need know what is the context of this job and what it is trying to do to understand what the failure is. |
|
This job is trying to generate reports right? what I see is that it clones checkstyle repo and the report generation failed with this message #878 (comment). So what source code do you refer to? I see no extra info in this CI failure |
each section has a title. The title of section with the job failure is |
|
I tried to run this script on local, build was successful |
98ee02e to
ad0a031
Compare
|
CI is green idk why it failed before please consider merging |
|
Can you provide the link to the source of the job? |
|
contribution/.ci/validation.sh Lines 35 to 46 in fb4a65b |
|
So this test regression on checkstyle's master against itself and runs regression on checkstyle project only. The default config file is really set up to produce no violations. It is basically a no harms test of the diff groovy. It uses It didn't specify what the error was, so we won't know what the issue was. So its failure does seem unrelated. |
|
Since this says for github actions, I assume this means in main repo. Is this file and openjdk17 used anywhere in main repo that we have switch it out once this is merged? |
|
I don't think so. This file is not in the main repo. Updating this file in this PR is enough. It is used in diff-report.yml I just don't know why we have those files:
They are not used anywhere why are we keeping them? |
It is only enough if the main repo does not make use of this file or this property you changed. If we made use of this in main repo, we would most likely get a failure after merge since openjdk17 no longer exists.
So this is only used for default configuration for regression. Users can supply an override and all projects in this file should be uncommented. |
Are we keeping these files for some reason? They were added over a year ago and they just say |
| # RequireThis usage | ||
| spring-integration|git|https://github.com/spring-projects/spring-integration|main| | ||
|
|
||
| # openjdk 17 requires lots of excludes, list here should be consistent with file filters at https://github.com/checkstyle/checkstyle/blob/master/.ci/openjdk17-excluded.files |
There was a problem hiding this comment.
@nrmancuso This line says it must have excludes consistent with main repo. Are you sure we can remove all excludes?
This was added in f8728f0 almost 2 1/2 years ago.
There was a problem hiding this comment.
There was a problem hiding this comment.
I tried to catch up with discussions
We used to have an exclude list (for non-compilable files) for all projects in this file. but we then removed all excludes from all projects because it turned out that these excluded files were ignored. We removed them to be consistent with previous reports.
After that, we added support for exclude option with --allowExcludes. But we never returned the exclude list to the projects list.
Then we added this openjdk17 with this huge exclude list.
I can confirm that this file (projects-to-test-on-for-github-action.properties) isn't used by any other task like no-exception. It is only used as a DEFAULT_PROJECTS_LINK in diff-report.yml. So, removing this exclude list and openjdk17 will not affect any other task.
now the question should we add an exclude list for the new openjdk21? If yes, then why don't we add an exclude list for the other projects?
Should we add an exclude list for the new openjdk21?
I don't think we gain any thing if we add it. we have 2 cases :
-
non-compilable file and can't be parsed by CS: This will get ignored due to the
skipFileOnJavaParseExceptionnew treewalker property -
non-compilable file but can be parsed (example): This will have no parse exception so will not be skipped and it will appear in the report. Is this acceptable? for me, I don't think we will lose anything by not excluding those files On the contrary they might help ensure regression (example for a non-compilable file that shows that the check update is as expected from this PR)
I am not sure if we should add files filters for these files, though, since they are how I confirmed logic of check update.
There was a problem hiding this comment.
@nrmancuso
Please correct me if anything is wrong I tried to go quickly over the blame of this file. You must have strong opinion because all these PR are created by you :)
There was a problem hiding this comment.
non-compilable file but can be parsed (example): This will have no parse exception so will not be skipped and it will appear in the report. Is this acceptable? for me, I don't think we will lose anything by not excluding those
Thanks a lot for such detailed post.
There is a nuance. If file is not compile able by javac, but parse able by checkstyle - target Check will execute and produce some violations or no violations.
It will be very confusing, as in report it will looks like diff in behavior and will be red flag for all reviewers. It will be not easy to catch a fact that this file is not legitimate to run on.
Removal of excludes is prone to cause bunch of false investihations for author of PR or bad requests from maintainers to investigate differences.
I think we need to keep exclude list for open jdk.
There was a problem hiding this comment.
How do we even know these files?
it was hard work of @nrmancuso .
can we find any way to know not compilable by javac, but parse able by checkstyle files
only by pratice and spotting something weird in diff report.
We can make a script to find all, but I am not sure that it is reasonable to do this at summer.
In this case, the excludes is for non-parseable files only which can be completely ignored by the treewalker property
should be skipped completely for diff report.
Treewalker can handle all, this list is for known files that can give weird behavior and confuse readers of diff report.
There was a problem hiding this comment.
These exclusions are to avoid having to analyze files that don't matter (noncompilable) or that we don't support parsing. It is generated by bash/python from here.
Let's just generate these and move on, we can debate the value of having these in another issue
There was a problem hiding this comment.
Look like @nrmancuso , agree to keep this list but content might be different.
There was a problem hiding this comment.
@nrmancuso @romani done please approve pr
issue :
#881
|
Files are added in this PR Unfortunately no reference to why we need this. |
Then we should have a good reference in this PR about why we did this update before merge to help future us :) I tried to explain here #878 (comment) |
romani
left a comment
There was a problem hiding this comment.
I placed reason to keep excludes in comment above
|
@mahfouz72 Since there is too much going on in this issue to possibly get lost, please move #878 (comment) to a new issue. We should have an issue if we are going to remove them anyways, otherwise, we will document why we need the files and possibly add the reason to the file(s). |
|
romani
left a comment
There was a problem hiding this comment.
Ok to merge.
Looks like we regenerated exclude list that is good.
|
test-configs will be updated to have openjdk21 checkstyle/test-configs#124 |
No description provided.