What feature do you want to see added?
Problem Description
When using the Agent Injection feature with Alpine-based containers, the plugin always injects the standard glibc-based jenkins-agent binary
from the default image (jenkins/inbound-agent:3355.v388858a_47b_33-3-jdk21). This causes runtime failures because Alpine uses musl libc instead
of glibc, making the binaries incompatible.
Current Behavior
- Agent injection always uses the default jenkins-agent image
- The only customization available is the
jnlpregistry setting at the cloud level, which adds a registry prefix but doesn't allow specifying a
different image variant
- Alpine-based agent containers fail at runtime with binary incompatibility errors
Expected Behavior
Users should be able to specify a custom agent injection image (e.g., Alpine variant) when their agent container is Alpine-based.
Proposed Solution
Add a new optional configuration field agentInjectionImage to the PodTemplate that allows users to specify a custom image for agent injection.
Priority order:
- Template-level
agentInjectionImage (most specific)
- Cloud-level
jnlpregistry prefix (existing behavior)
- System property prefix (existing behavior)
- Default image (existing behavior)
Use Case
Organizations using Alpine-based containers for smaller image sizes and security benefits need to ensure the injected jenkins-agent binaries are
compatible with Alpine's musl libc.
Example Configuration
Pipeline DSL:
podTemplate(
agentInjection: true,
agentInjectionImage: 'jenkins/inbound-agent:3355.v388858a_47b_33-3-alpine-jdk21',
containers: [
containerTemplate(
name: 'jnlp',
image: 'my-registry/eclipse-temurin:21-jdk-alpine'
)
]
) {
node(POD_LABEL) {
// Your pipeline code
}
}
UI Configuration:
- Pod Template → Enable "Inject Jenkins agent in agent container"
- Set "Agent injection image" field to: jenkins/inbound-agent:3355.v388858a_47b_33-3-alpine-jdk21
Benefits
- ✅ Supports heterogeneous environments (mixed Alpine and standard containers)
- ✅ Per-template granularity (different templates can use different agent images)
- ✅ Fully backward compatible (existing templates work unchanged)
- ✅ No assumptions about image naming conventions
- ✅ Supports custom/private registries and images
Important Notes
The jenkins-agent script requires bash. Alpine-based containers should include bash:
FROM alpine:3.23
RUN apk add --no-cache bash openjdk21-jre
Alternative Approaches Considered
1. Cloud-level default: Could add a cloud-level setting, but template-level provides more flexibility for mixed environments
2. Auto-detection: Could detect Alpine containers, but explicit configuration is more predictable and reliable
3. Variant flag: Could use boolean/enum for "alpine" vs "standard", but full image string supports any registry/tag/variant
Related
- Alpine Linux uses musl libc vs standard glibc
- Official jenkins-agent Alpine images: jenkins/inbound-agent:*-alpine-*
### Upstream changes
_No response_
### Are you interested in contributing this feature?
Yes
What feature do you want to see added?
Problem Description
When using the Agent Injection feature with Alpine-based containers, the plugin always injects the standard glibc-based jenkins-agent binary
from the default image (
jenkins/inbound-agent:3355.v388858a_47b_33-3-jdk21). This causes runtime failures because Alpine uses musl libc insteadof glibc, making the binaries incompatible.
Current Behavior
jnlpregistrysetting at the cloud level, which adds a registry prefix but doesn't allow specifying adifferent image variant
Expected Behavior
Users should be able to specify a custom agent injection image (e.g., Alpine variant) when their agent container is Alpine-based.
Proposed Solution
Add a new optional configuration field
agentInjectionImageto the PodTemplate that allows users to specify a custom image for agent injection.Priority order:
agentInjectionImage(most specific)jnlpregistryprefix (existing behavior)Use Case
Organizations using Alpine-based containers for smaller image sizes and security benefits need to ensure the injected jenkins-agent binaries are
compatible with Alpine's musl libc.
Example Configuration
Pipeline DSL:
podTemplate( agentInjection: true, agentInjectionImage: 'jenkins/inbound-agent:3355.v388858a_47b_33-3-alpine-jdk21', containers: [ containerTemplate( name: 'jnlp', image: 'my-registry/eclipse-temurin:21-jdk-alpine' ) ] ) { node(POD_LABEL) { // Your pipeline code } } UI Configuration: - Pod Template → Enable "Inject Jenkins agent in agent container" - Set "Agent injection image" field to: jenkins/inbound-agent:3355.v388858a_47b_33-3-alpine-jdk21 Benefits - ✅ Supports heterogeneous environments (mixed Alpine and standard containers) - ✅ Per-template granularity (different templates can use different agent images) - ✅ Fully backward compatible (existing templates work unchanged) - ✅ No assumptions about image naming conventions - ✅ Supports custom/private registries and images Important Notes The jenkins-agent script requires bash. Alpine-based containers should include bash: FROM alpine:3.23 RUN apk add --no-cache bash openjdk21-jre Alternative Approaches Considered 1. Cloud-level default: Could add a cloud-level setting, but template-level provides more flexibility for mixed environments 2. Auto-detection: Could detect Alpine containers, but explicit configuration is more predictable and reliable 3. Variant flag: Could use boolean/enum for "alpine" vs "standard", but full image string supports any registry/tag/variant Related - Alpine Linux uses musl libc vs standard glibc - Official jenkins-agent Alpine images: jenkins/inbound-agent:*-alpine-* ### Upstream changes _No response_ ### Are you interested in contributing this feature? Yes