Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modernize the tool #39

Merged
merged 28 commits into from
Sep 10, 2022
Merged

Modernize the tool #39

merged 28 commits into from
Sep 10, 2022

Conversation

MarkEWaite
Copy link
Contributor

@MarkEWaite MarkEWaite commented Aug 2, 2022

Modernize the tool

Reduce spotbugs warnings.

  • Remove unread field
  • Fix default encoding spotbugs warnings
  • Do not use same class name as super class
  • Don't ignore return values from File methods
  • Exclude EI_EXPOSE_REP2 spotbugs warning
  • Exclude command injection spotbugs warning

Squash merge please, so that the clutter is not included in the upstream repository history.

@MarkEWaite
Copy link
Contributor Author

Needs a detailed comparison of the console output on the master branch with the results from this pull request. Some of the messages in the pull request build that are not in the master build include:

Failed to process BlazeMeterJenkinsPlugin
Failed to process DotCi-Fig-template
Failed to process JDK_Parameter_Plugin
Failed to process JiraTestResultReporter
Failed to process Surround-SCM-plugin
Failed to process TestFairy
Failed to process advanced-installer-msi-builder
Failed to process all-changes
Failed to process appaloosa-plugin
Failed to process artifact-diff-plugin
Failed to process assembla-merge-request-builder
Failed to process aws-bucket-credentials
Failed to process aws-lambda
Failed to process aws-yum-parameter
Failed to process bds-plugin
Failed to process bitbucket-approve
Failed to process build-env-propagator
Failed to process build-environment
Failed to process build-publisher
Failed to process build-requester
Failed to process build-timestamp
Failed to process cerberus-testing
Failed to process changelog-history
Failed to process clamav
Failed to process cli-commander
Failed to process cloudtest
Failed to process cloverphp
Failed to process cluster-stats

@basil
Copy link
Contributor

basil commented Sep 7, 2022

This PR introduces a number of new failures at runtime compared to #41 that is the opposite, an 85% reduction in failures; however, this PR tackles some SpotBugs issues which #41 does not. Suggest merging #41 first and then turning this PR into a dedicated SpotBugs cleanup PR.

@basil
Copy link
Contributor

basil commented Sep 7, 2022

Actually the latest run of this PR is even better than #41:

Fixed failures:
1296

New failures:
1
+++ newf        2022-09-07 14:37:53.148885328 -0700
+Failed to process AnchorChain

So maybe we should take this PR instead after all!

@basil
Copy link
Contributor

basil commented Sep 7, 2022

I think I have one theory why this PR only adds 1 new test failure while #41 adds 167 new failures: this PR is continuing to compile the code with Java 8 bytecode and then running it with Java 8, while #41 compiles the code with Java 11 bytecode and runs with Java 11. I suspect the 167 new failures in #41 are plugins that don't compile with Java 11. Since those 167 new failures are all relatively obscure plugins, it might be worth preferring #41 to get to Java 11 faster. If that long tail of 167 plugins is deemed important, I could update #41 to retain Java 8 compilation and Java 8 at runtime and that should get that PR down to the same set of new failures as in this PR.

@MarkEWaite
Copy link
Contributor Author

If that long tail of 167 plugins is deemed important, I could update #41 to retain Java 8 compilation and Java 8 at runtime and that should get that PR down to the same set of new failures as in this PR.

That is the approach I would prefer. I think we need to retain Java 8 compilation and Java 8 runtime for now. Even though the 167 new failures are relatively obscure plugins, I'd rather retain them in the output than lose them.

Could we set a timeout and declare that we'll switch this tool to Java 11 in 6 months and accept that in 6 months some portion of those 167 relatively obscure plugins will be dropped from the extension point documentation?

@basil
Copy link
Contributor

basil commented Sep 8, 2022

Could we set a timeout and declare that we'll switch this tool to Java 11 in 6 months and accept that in 6 months some portion of those 167 relatively obscure plugins will be dropped from the extension point documentation?

That makes sense to me, though in practice I doubt the list will have changed in 6 months and I think the only practical effect this will have will be to delay progress by 6 months. But the principle of announcing a deprecation period and giving consumers time to adapt is sound. I have pushed commit 7c641b6 to #41; let's see if the failure rate now matches this PR (hopefully it should).

@MarkEWaite
Copy link
Contributor Author

Could we set a timeout and declare that we'll switch this tool to Java 11 in 6 months and accept that in 6 months some portion of those 167 relatively obscure plugins will be dropped from the extension point documentation?

That makes sense to me, though in practice I doubt the list will have changed in 6 months and I think the only practical effect this will have will be to delay progress by 6 months.

I think you're right. I looked at those 167 plugins and saw none of them that were valuable enough to retain in extension documentation. I think we do not need to wait the 6 months. Those 167 plugins are very obscure. If a maintainer of one of those plugins chooses to modernize it, the plugin will reappear in the extensions list.

@basil
Copy link
Contributor

basil commented Sep 8, 2022

Let's at least complete the thought experiment in #41 to prove or disprove my theory. If my theory is correct then you can make the final decision about whether to keep commit 7c641b6 or to retain it.

@basil
Copy link
Contributor

basil commented Sep 8, 2022

OK, my latest run of #41 with commit 7c641b6 and commit 5a81e5b confirms my theory:

Fixed failures:
1206

New failures:
3
+++ newf        2022-09-08 11:10:23.972654095 -0700
+Failed to process JiraTestResultReporter
+Failed to process jobConfigHistory
+Failed to process machine-learning

So running backend-extension-indexer with Java 11 will effectively drop support for the 167 least-maintained Jenkins plugins of all time. I took a look at them and they are all 7-12 years old and dormant.

So how do you want to proceed Mark? My preference would be:

  • Squash merge Refresh component #41, either with commit 7c641b6 and commit 5a81e5b (thus retaining support for the 167 least-maintained Jenkins plugins) or without them (thus dropping support for the 167 least-maintained Jenkins plugins)
  • Rebase this PR on top of the result and turn it into a dedicated SpotBugs cleanup PR

The reason I want to take #41 over this PR for the non-SpotBugs changes is that I went a little further than you did by dropping support for Sorcerer which is a good future-proofing move.

@MarkEWaite
Copy link
Contributor Author

MarkEWaite commented Sep 8, 2022

So how do you want to proceed Mark? My preference would be:

  • Squash merge Refresh component #41, either with commit 7c641b6 and commit 5a81e5b (thus retaining support for the 167 least-maintained Jenkins plugins) or without them (thus dropping support for the 167 least-maintained Jenkins plugins)
  • Rebase this PR on top of the result and turn it into a dedicated SpotBugs cleanup PR

The reason I want to take #41 over this PR for the non-SpotBugs changes is that I went a little further than you did by dropping support for Sorcerer which is a good future-proofing move.

I think we should procced with your preference. I'm very glad that you dropped sorcerer and went further on the spotbugs fixes.

I haven't done comparisons of the files written by the tool before this change compared to the files written by the tool after the change. Is that comparison worth the effort or would we rather perform the merge and then review the results on the www.jenkins.io extensions page so that we can see them in context?

Addendum - I just read the comment on #41 that notes it has significantly reduced the number of failures reported by the current version of the tool. That seems like it makes it unreasonable to compare the output. Better to merge #41, run the indexer, build the www.jenkins.io site, and explore the extensions pages there.

@basil
Copy link
Contributor

basil commented Sep 8, 2022

I think we should proceed with your preference.

OK great, so can you make a decision about the 167 least-maintained plugins of all time (which I intentionally left out of my preference). If you want to retain support for them I will retain commit 7c641b6 and commit 5a81e5b in #41. If you want to drop support for them I will drop commit 7c641b6 and commit 5a81e5b from #41.

I'm very glad that you dropped sorcerer and went further on the spotbugs fixes.

Well I didn't go further on the SpotBugs fixes at all; in fact, I didn't tackle them at all. That's why I was proposing to keep this PR open and rebase it on top of #41 as a SpotBugs-focused PR.

Is that comparison worth the effort

I will do some more testing on the proudced output as you have requested.

@MarkEWaite
Copy link
Contributor Author

MarkEWaite commented Sep 8, 2022

OK great, so can you make a decision about the 167 least-maintained plugins of all time?

Drop support for them, don't include commit 7c641b6 or commit 5a81e5b from #41

@basil
Copy link
Contributor

basil commented Sep 8, 2022

Great, I have dropped those commits from #41, which is now back to its starting state of fixing 1154 failures and introducing 167 new failures (for the 167 least-maintained plugins of all time).

Next I will focus on performing the additional testing you have requested.

@basil
Copy link
Contributor

basil commented Sep 8, 2022

Next I will focus on performing the additional testing you have requested.

Done in #41 (comment)

Copy link
Contributor

@basil basil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! Nice job!

pom.xml Outdated Show resolved Hide resolved
pom.xml Outdated Show resolved Hide resolved
@@ -186,7 +190,7 @@ public static void main(String[] args) throws Exception {
public JSONObject getJsonUrl(String url) throws MalformedURLException, IOException {
try (
InputStream is = new URL(url).openStream();
InputStreamReader isr = new InputStreamReader(is);
InputStreamReader isr = new InputStreamReader(is, "UTF-8");
Copy link
Contributor

@basil basil Sep 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This made sense in Java 8, but now that the code base is on Java 11 we can use the more specific type:

Suggested change
InputStreamReader isr = new InputStreamReader(is, "UTF-8");
InputStreamReader isr = new InputStreamReader(is, StandardCharsets.UTF_8);

(Plus import java.nio.charset.StandardCharsets; at the top.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resolved in 48046e6

Comment on lines 311 to 312
try (PrintWriter w = new PrintWriter(new File(asciidocOutputDir, "index.adoc"), "UTF-8")) {
IOUtils.copy(new InputStreamReader(getClass().getResourceAsStream("index-preamble.txt"), "UTF-8"), w);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto:

Suggested change
try (PrintWriter w = new PrintWriter(new File(asciidocOutputDir, "index.adoc"), "UTF-8")) {
IOUtils.copy(new InputStreamReader(getClass().getResourceAsStream("index-preamble.txt"), "UTF-8"), w);
try (PrintWriter w = new PrintWriter(new File(asciidocOutputDir, "index.adoc"), StandardCharsets.UTF_8)) {
IOUtils.copy(new InputStreamReader(getClass().getResourceAsStream("index-preamble.txt"), StandardCharsets.UTF_8), w);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resolved in 48046e6

Comment on lines 323 to 324
try (PrintWriter w = new PrintWriter(new File(asciidocOutputDir, m.getUrlName() + ".adoc"), "UTF-8")) {
IOUtils.copy(new InputStreamReader(getClass().getResourceAsStream("component-preamble.txt"), "UTF-8"), w);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto:

Suggested change
try (PrintWriter w = new PrintWriter(new File(asciidocOutputDir, m.getUrlName() + ".adoc"), "UTF-8")) {
IOUtils.copy(new InputStreamReader(getClass().getResourceAsStream("component-preamble.txt"), "UTF-8"), w);
try (PrintWriter w = new PrintWriter(new File(asciidocOutputDir, m.getUrlName() + ".adoc"), StandardCharsets.UTF_8)) {
IOUtils.copy(new InputStreamReader(getClass().getResourceAsStream("component-preamble.txt"), StandardCharsets.UTF_8), w);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resolved in 48046e6

Comment on lines 122 to 124
final File tempDir = File.createTempFile("jenkins","extPoint");
tempDir.delete();
tempDir.mkdirs();
Files.delete(tempDir.toPath());
Files.createDirectories(tempDir.toPath());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If what you're looking for is a temporary directory, Files#createTempDirectory is a more straightforward path to get there and avoids a race condition that I think Jonathan Leitschuh has been working on fixing throughout the entire planet with automated PRs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Included in 4f8dd3b

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We fixed the temporary directory creation issue, but I'm not sure whether this repository also contains a zip slip issue. @JLLeitschuh are you interested in running your tool against it and creating a PR if there is a zip slip issue?

Copy link

@JLLeitschuh JLLeitschuh Sep 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think Jonathan Leitschuh has been working on fixing throughout the entire planet with automated PRs.

I have been, this is a hilarious way of phrasing this one 😆 ❤️

We fixed the temporary directory creation issue, but I'm not sure whether this repository also contains a zip slip issue. @JLLeitschuh are you interested in running your tool against it and creating a PR if there is a zip slip issue?

If you could do me a kind favor and get any projects (ie probably this entire org) you do want me to generate PRs against indexed into this project, I'd be more than happy to PR generation! 🎉

https://github.com/moderneinc/jenkins-ingest

Copy link
Contributor

@basil basil Sep 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I do not understand what you are asking me to do. I just thought you might be interested in contributing another helpful automated PR, as you have in the past. If you are not, no problem. We appreciate your past contributions!

@MarkEWaite MarkEWaite marked this pull request as ready for review September 10, 2022 00:13
@MarkEWaite MarkEWaite merged commit 1953d69 into jenkins-infra:master Sep 10, 2022
@MarkEWaite MarkEWaite deleted the modernize branch September 10, 2022 02:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants