bump java to 11

[jetersen]

fixes #5

[basil]

I just manually ran the CD workflow on jenkins-test-harness-htmlunit: https://github.com/jenkinsci/jenkins-test-harness-htmlunit/runs/7050646405

Based on https://github.com/jenkinsci/jenkins-test-harness-htmlunit/blob/47b052d78bca46bf07aa57fd208a408080889e65/.github/workflows/cd.yaml#L12= I thought I would get https://github.com/jenkins-infra/github-reusable-workflows/blob/v1.1.0/.github/workflows/maven-cd.yml i.e. Temurin 11.

But looking at the logs I got Temurin 8 which I did not expect:

Run actions/setup-java@v3
Resolved Java 8.0.332+9 from tool-cache
Setting Java 8.0.332+9 as the default
Java configuration:
  Distribution: temurin
  Version: 8.0.332+9
  Path: /opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/8.0.332-9/x64
Creating settings.xml with server-id: github

The release happened to work because the test harness is a special core component that still supports Java 8:

+ mvn -B -V -s /home/runner/work/_actions/jenkins-infra/jenkins-maven-cd-action/v1.3.1/settings.xml -ntp -Dstyle.color=always -Dset.changelist -DaltDeploymentRepository=maven.jenkins-ci.org::default::https://repo.jenkins-ci.org/releases/ -Pquick-build '-P!consume-incrementals' clean deploy
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /usr/share/apache-maven-3.8.6
Java version: 1.8.0_332, vendor: Temurin, runtime: /usr/lib/jvm/temurin-8-jdk-amd64/jre
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "5.13.0-1031-azure", arch: "amd64", family: "unix"

But I think if I had been trying to release e.g. Remoting or Stapler it would have failed.

[basil]

Is it possible that the presence of https://github.com/jenkins-infra/github-reusable-workflows/releases/tag/v1 means that https://github.com/jenkinsci/jenkins-test-harness-htmlunit/blob/47b052d78bca46bf07aa57fd208a408080889e65/.github/workflows/cd.yaml#L12= is fetching the specific tag v1 (which is still using Temurin 8) rather than the latest tag v1.1.0 (which is using Temurin 11)?

[jglick]

Yes, see https://github.com/jenkins-infra/github-reusable-workflows/pull/6#discussion_r897368398. @jetersen I think we can revert the reversion and let v1 float back up to v1.1.0? If someone feels strongly otherwise, they should file a PR changing main and we can discuss, but I do not think we should deliberately hold back a v1 tag except on a temporary emergency basis.

I can also release #11 which is just sitting there.

[jglick]

Done. I think https://github.com/jenkins-infra/github-reusable-workflows/tags + https://github.com/jenkins-infra/github-reusable-workflows/releases should make more sense now.

[basil]

Thank you!

[jetersen]

Thanks!