Add a github workflow that checks common (and less common) gradle tasks when gradle version is changed

[dweiss]

This is mostly an automated sanity check that common (and less common) tasks work after an upgrade. This is what the output looks like:

https://github.com/dweiss/lucene/actions/runs/9389691271

[dweiss]

This is a follow up to #13453 - perhaps it'll make life a bit easier.

[ChrisHegarty]

I think that this is good. Would it run on all CI jobs, or you somehow opt-in?

Running with RUNTIME_JAVA_HOME does have a slightly different code path in the gradle build files. Not sure if that could be easily covered.

I just merged the gradle wrapper update to main and branch_9x, so maybe sync up this PR branch to ensure that all is still good. :-)

[dweiss]

I think that this is good. Would it run on all CI jobs, or you somehow opt-in?

There is a filtering restriction - it'll run on PRs and pushes to these two branches and when the commit matches path specs. I think this restricts it reasonably well.

    branches:
      - 'main'
      - 'branch_9x'
    paths:
      - '.github/workflows/run-checks-gradle-upgrade.yml'
      - 'gradle/wrapper/**'

Running with RUNTIME_JAVA_HOME does have a slightly different code path in the gradle build files. Not sure if that could be easily covered.

Yes, I think so. The run-nightly-smoketester.yml workflow uses this explicit variable to test against 22-ea.

There are probably more tasks/ paths to cover. This is just a PoC and a start.

[dweiss]

Let me close this PR so that it doesn't rerun all the checks while I'm trying to figure it out locally.

[dweiss]

this is the configuration matrix switch that is used to control whether the build runs with a separate RUNTIME_JAVA_HOME or without it.

[dweiss]

If we're running with the "uses-alt-java" switch, we set up an "alternative" java distribution under /tmp and use it to execute the same set of gradle tasks.

[dweiss]

I've added a matrix configuration so that one job runs with RUNTIME_JAVA_HOME and the other without it. Seems to be working and increases test coverage.

[dweiss]

I think this is ready and works reasonably well - it caught #13458 already.

[ChrisHegarty]

Thanks for this @dweiss LGTM (and thanks for catching and fixing the issue I caused by updating the wrapper)