chore: keep only one Dockerfile per Linux image variant

[lemeurherve]

This PR simplifies this repo content by keeping only one Dockerfile per Linux image variant like the Windows images, versus one per JDK and per Linux image variant currently.

Notes:

• Use the JDK17 image (current default Jenkins JDK version) from each variant as their new unique Dockerfile base
  • Moving commit: 214019e
  • Cleanup commit: c33b4af
  • Little exception for Almalinux & RHEL ubi8: they only have one JDK11 version, used as bases.
• Factorize jlink command depending on the JDK version and adapt docker bake paths:
  • Distinct commit: a181b22
  • This jlink code block is based on a proven implementation coming from the agent images: https://github.com/jenkinsci/docker-agent/blob/e2560a929884a1f1cfe3c64001b1b2932d8e7057/debian/Dockerfile#L32-L51
  • I've adapted it to be POSIX compliant as the Alpine ash shell doesn't support arrays: https://github.com/jenkinsci/docker/pull/1857/files#diff-e65ec3bff5dbf5186d16b4f5630439bbe16f82258447f5f212ad42e4ac897e60R28-R33
    • Side note: this should probably be replicated in the Alpine agent image, which doesn't currently specify any shell
  • I'm also passing a new JLINK_COMPRESS argument depending on the JDK version as a Dockerfile ARG
    • I find it cleaner than adding conditions in the RUN if case else block, which would also be challenging in the Alpine variant due to the lack of arrays support by ash.
    • Reworked in b8ff4f7 and e672c5c to take in account the following review: chore: keep only one Dockerfile per Linux image variant #1857 (review)
      • This wasn't that challenging actually
      • I took the opportunity to keep only the POSIX shell compliant version everywhere using set instead of arrays
  • Again, little exception for Almalinux & RHEL ubi8: as they only have one JDK11 version, their Dockerfiles remain untouched.
• I've done a last little bit of quoting to satisfy shellcheck: 1e0037b

For the record, initial image content changes extracted to other merged pull requests:

• Non integration of the install-plugins.sh shell script in JDK11 images:
  • Deprecated since September 2020
  • Does only echo a warning since Remove install-plugins.sh #1408 almost two years ago: https://github.com/jenkinsci/docker/blob/bed10d624086e931cf1d053d62174a2355cfd15c/install-plugins.sh
  • I think it's time for it to go, it shouldn't functionally change anything for the end users anyway.
  • Extracted to cleanup: remove deprecated install-plugin.sh script from Linux jdk11 images #1863 if it needs to be merged separately.
• JDK21 specific compression argument set to zip-6 like Linux for Windows image:
  • 7d18171
  • Complement of chore(windows): Switch from Temurin base images to Temurin JDK binaries #1848 which introduced jlink in the Windows controller image
    • Note: jlink on Windows should be properly tested, might worth its own issue
  • Extracted to fix: set jlink compression arg to zip-6 for Windows jdk21 image #1864 if it needs to be merged separately.

I'll create a follow-up pull request to adapt updatecli manifests to these changes. (Preview: 65353f9)

This PR is a first step, I'd like to factorize a bit the logic of the docker bake around jdk versions after that.

Testing done

Local builds + CI

Submitter checklist

Beta Give feedback

1. Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
2. Ensure that the pull request title represents the desired changelog entry
3. Please describe what you did
4. Link to relevant issues in GitHub or Jira
5. Link to relevant pull requests, esp. upstream and downstream changes
6. Ensure you have provided tests - that demonstrates feature works or fixes the issue

[dduportal]

Started to review this change. It is really good work.

I'm having mixed feeling, for the jlink about the --compress factorization you made with an ARG while keeping a condition around JDK11 or JDK17+ around the debug flags. Without looking at the original code where this comes from, I find it really confusing to have the jlink flags setups spread between a shell instruction inside a Dockerfile and a docker-bake declarative directive.

I would either move all the "varying per JDK" flags as an ARG or all in a shell instruction (and factorize this "hard to read" shell into a separated shell script so we can really factorize).

[lemeurherve]

Addressed spread in b8ff4f7 and e672c5c with minimal complexity.

Not sure putting this into a separate script is mandatory for this PR.

[olivergondza]

On behalf of rhel images, I can say I do not object, as the matrix of versions and jdks remain unchanged. Added one question/suggestion.

[olivergondza]

Q: Why is this using set -- ...?
IIUC, it requires every branch to set the same amount of arguments so they can be referred to as $1 and $2 — that feels hard to obey going forwards. Using an array variable seems to do the trick without being as cryptic, and permitting varying argument count.

[dduportal]

Alas on Alpine Linux, the shell is ash which does not support arrays.

The set -- ... syntax is a way to simulate arrays. The code could be enforced to ensure the same amount of flags is provided, but what would be the probability of such an error? (I really have no idea)

[lemeurherve]

The use of set instead of arrays like in https://github.com/jenkinsci/docker/pull/1857/files#diff-e65ec3bff5dbf5186d16b4f5630439bbe16f82258447f5f212ad42e4ac897e60R28-R33 is motivated by the fact that Alpine ash shell (amongst others) doesn't support them.
Ref: https://github.com/koalaman/shellcheck/wiki/SC3054

Thus using a POSIX shell compliant version of the same script everywhere seems better to me than having a distinct one for Alpine.
I could be wrong but I don't foresee a lot of new jlink arguments. If so this could be revised at that time in my opinion.

EDIT to add that this script and these arguments aren't reused elsewhere than in this intermediate layer and that it isn't directly actionable from an end user perspective.

[MarkEWaite]

Initial review started but not finished.

[MarkEWaite]

I don't think we should attempt to preserve armv7 support since Eclipse Temurin does not offer armv7 support.

[lemeurherve]

This comes from the docker agent model I've used: https://github.com/jenkinsci/docker-agent/blob/be371a370e50e5627d389ecd975d437f2abac2cf/debian/Dockerfile#L35-L51

Still targeted there: https://github.com/jenkinsci/docker-agent/blob/be371a370e50e5627d389ecd975d437f2abac2cf/docker-bake.hcl#L248

But not in this repo: https://github.com/jenkinsci/docker/blob/f6c4ef1e61737f45e6946a0bf6556c3aa9909dc4/docker-bake.hcl

I'll remove it.

[lemeurherve]

I don't think we should attempt to preserve armv7 support since Eclipse Temurin does not offer armv7 support.

Might worth adding it to the Platform SIG for docker agent images?

[lemeurherve]

I'll remove it.

Removed in 91048d2

[lemeurherve]

Opened #1857 & #1864 if the minor image changes of this PR need to be merged separately.

EDIT: merged.

[MarkEWaite]

I compared the list of files in the container images before and after this change and the differences all seemed reasonable to me. I think it is ready to merge.