support agent jdk injection

[zhan9san]

Fix #2824

Testing done

SOLUTION

Add agentJdkInjection field that injects JDK from the agent image at runtime.
Toolchain images no longer need Java - they stay pure build environments.

BENEFITS

• Build images decoupled from Jenkins - no Java needed
• Jenkins upgrades don't require rebuilding toolchain images
• Update agent version once, all pods get new agent automatically
• Cleaner separation: toolchains for builds, agent for Jenkins communication

USAGE

Jenkins UI configuration:
☑ Inject Jenkins agent in agent container
☑ Inject JDK from agent image

Pod template:

• Agent container: python:3.11-slim (pure Python, no Java)
• Agent injection image: jenkins/inbound-agent:alpine-jdk21

Result: JDK injected at pod startup, agent runs with injected Java

BACKWARD COMPATIBILITY

• Fully backward compatible - disabled by default
• Existing pod templates work unchanged
• No migration needed
• Only applies when explicitly enabled

TRADE-OFFS

• Adds 10-20 seconds to pod startup (one-time JDK copy)
• Requires ~200MB volume space per pod

Here is the template config

Here is the job output

spec:
  containers:
  - command:
    - "/jenkins-agent/jenkins-agent"
    env:
    - name: "JENKINS_SECRET"
      value: "********"
    - name: "JENKINS_AGENT_NAME"
      value: "test-label-6vxt2"
    - name: "JENKINS_AGENT_FILE"
      value: "/jenkins-agent/agent.jar"
    - name: "JENKINS_WEB_SOCKET"
      value: "true"
    - name: "REMOTING_OPTS"
      value: "-noReconnectAfter 1d"
    - name: "JENKINS_NAME"
      value: "test-label-6vxt2"
    - name: "JENKINS_AGENT_WORKDIR"
      value: "/home/jenkins/agent"
    - name: "JENKINS_URL"
      value: "http://10.66.40.223:8080/"
    - name: "JENKINS_JAVA_BIN"
      value: "/jenkins-agent/jdk/bin/java"
    image: "cn-build-nexus.example.com/example-docker-preprod/python:3.13-slim"
    name: "jnlp"
    resources:
      requests:
        memory: "256Mi"
        cpu: "100m"
    tty: true
    volumeMounts:
    - mountPath: "/jenkins-agent"
      name: "jenkins-agent"
      readOnly: true
    - mountPath: "/home/jenkins/agent"
      name: "workspace-volume"
      readOnly: false
    workingDir: "/home/jenkins/agent"
  hostNetwork: false
  initContainers:
  - command:
    - "/bin/sh"
    - "-c"
    - "cp $(command -v jenkins-agent) /jenkins-agent/jenkins-agent;cp -R /usr/share/jenkins/.\
      \ /jenkins-agent;cp -R /opt/java/openjdk /jenkins-agent/jdk"
    image: "cn-build-nexus.example.com/example-docker-preprod/jenkins/inbound-agent:3355.v388858a_47b_33-3-jdk21"
    name: "set-up-jenkins-agent"
    volumeMounts:
    - mountPath: "/jenkins-agent"
      name: "jenkins-agent"

Submitter checklist

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

[zhan9san]

@jglick

Would you mind taking a look at this PR whenever you have a moment? No rush at all. Thank you so much!

[jglick]

Interesting thought but this assumes that

• the stock agent image includes a JRE in the specified location (at least CloudBees CI overrides the default image with a different one based on UBI, just sharing the launcher script with the OSS version)
• the JRE uses only shared libraries also present in the selected agent image, and in compatible versions

This seems fragile.

[zhan9san]

Thanks for your review

The same concern actually applies to agentInjection itself — PR #2823 was opened specifically because the default agent image is glibc-based and breaks on Alpine (musl) containers. That was addressed by adding agentInjectionImage to let users pick a compatible image.

agentJdkInjection follows the same pattern: it's an opt-in feature, and users pairing it with an Alpine-compatible agentInjectionImage (e.g. jenkins/inbound-agent:...-alpine-jdk21) would naturally get a JDK at /opt/java/openjdk too, since that path is standard for Eclipse Temurin across both glibc and Alpine images.

Let me know if you still have concerns.