Remove hard-coded Java version in security scan#36
Conversation
|
@strangelookingnerd A number of these YML files are inconsistent. Can you please normalize them to avoid hard-coding a Java version in any of these YML files: |
I will look into it. My template uses the default, however I left the property and its description in place (commented-out). I thought this allows maintainers to change it more easily without consulting the documentation first. |
|
This build obviously didn't need Java 11 to be hard-coded and I suspect almost all of the above are the same. I agree that it is nice to leave the defaults commented out to allow for customization. When there is a customization, the reason for the customization can be provided in a comment. A customization without a reason should not be retained. |
|
Thanks for your PR. I wanted to open a PR on https://github.com/jenkinsci/plugin-modernizer-tool to perform the cleanup (The GSoC 2024 project on openrewrite) But it looks there is a bug on the original recipe to comment out a YAML property |
|
Thank you very much! I have merged the PRs for critical plugins. If I have time I will try to go through the remaining long-tail plugins as well. |
|
For the Sonargraph Plugin, if I remove the Java version it defaults to Java 8 and that does not work. Higher Java versions should be ok... |
Hard-coding Java 11 is a bad idea since we plan to EOL it in the next few months.