Use separate nodeProjectDir for each subproject

[tylerbertrand]

Description

Sometimes, NpmTasks are failing with being unable to find files/commands under npmProjectDir. Here's an example of such a failure. The failing tasks always execute after the nodeSetup task for that project, so in theory, everything should be in place.

However, in this case, multiple subprojects share the same npmProjectDir. The way the gradle-node-plugin works, having multiple projects use the same npmProjectDir doesn't save work, and can actually cause timing issues like the failures we are seeing. This is because each nodeSetup task clears out the old directory before it unpacks it again. In the Timeline view of the same Build Scan linked above, we can see that the :solr:solr-ref-guide:downloadAntoraCli task (an NpmTask), is executing at the same time as :solr:packaging:nodeSetup, and downloadAntoraCli can't find node because it's been cleared out by another suproject's nodeSetup task.

Solution

This PR updates each subproject to use its own individual nodeProjectDir to avoid these timing issues. Separating these out doesn't result in node being downladed twice - despite unpacking the same version multiple times, it's only ever downloaded once. So no extra work is being done, since sharing the same nodeProjectDir doesn't save work in the first place, as explained above.

Tests

No new tests were added, and no existing tests were modified, but the check and integrationTests tasks consistently pass when run locally with these changes.

Checklist

Please review the following and check all that apply:

• I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
• I have created a Jira issue and added the issue ID to my pull request title.
• I have given Solr maintainers access to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation)
• I have developed this patch against the main branch.
• I have run ./gradlew check.
• I have added tests for my changes.
• I have added documentation for the Reference Guide

[epugh]

It seems to make sense, I wish I knew more to weigh in one way or the other, hopefully someone else gives a +1!

[github-actions]

This PR has had no activity for 60 days and is now labeled as stale. Any new activity will remove the stale label. To attract more reviewers, please tag people who might be familiar with the code area and/or notify the [email protected] mailing list. To exempt this PR from being marked as stale, make it a draft PR or add the label "exempt-stale". If left unattended, this PR will be closed after another 60 days of inactivity. Thank you for your contribution!

[github-actions]

This PR is now closed due to 60 days of inactivity after being marked as stale. Re-opening this PR is still possible, in which case it will be marked as active again.

[janhoy]

I see no reason for not doing this? Fixes a bug..

[janhoy]

@tylerbertrand Will you resolve the conflicts, then me or @epugh will get it merged?

[epugh]

thanks for reminding us @janhoy

[tylerbertrand]

@janhoy Sure, sounds good

[tylerbertrand]

Hi @janhoy and @epugh, the conflicts have been resolved

[epugh]

Thanks for the contribution @tylerbertrand!

[dsmiley]

I'm going to move the CHANGES.txt entry from "Bug fix" into the "Other" category because Solr itself does not have a bug.

Also note the Lucene project uses "GITHUB#1234" pattern; we might want to do similarly. It's more future-proof as some references are to issues not PRs specifically. I'm making this change as well.

[epugh]

Thanks @dsmiley ... I guess I was thinking as developer of Solr versus a user of Solr! And Changes.txt is meant for the user primarily!