[JENKINS-38620] Support common user stories for docker in builds

Having been working with developers using the Pipelines and docker containers, I'm seeing several user stories evolve:

1. As a developer, I'm trying to build my code in CI using a container, so that my software builds the same everytime.


2. As a developer, I'm trying to build my container in CI, so that my code is properly packaged and can be safely deployed.


3. As a developer, I'm trying to run functional/integration tests in CI using containers, so I can ensure my code will work in production.


4. As a devops engineer, I'm running arbitrary tasks in a container, so that tasks happen at appropriate times with respect to CI builds.

Some of these tasks require that the default WORKSPACE and USER is used in the container. Other tasks, like building source code, may require that /etc/passwd and /etc/group are updated with the Jenkins user and group.

I would propose that we break the docker pipeline interface up into two parts:

1. A raw wrapper around docker with some simple conveniences that won't interfere with doing any docker command desired. This interface will not set environment variables, WORKSPACE or USER.


2. A simplified interface that can accept an optional Dockerfile, automatically updates the /etc/passwd and /etc/group and puts the workspace in a single known location, like /build.

The simplified interface would be designed for the first user story above. The reason to use /build for the workspace is to prevent running into path names that are too long. The /etc/passwd and /etc/group is to ensure various build commands (some linker commands, go get, and some python and ruby} commands, especially test cases) will work, yet let us also ensure files written to {{/build are owned by the correct user/group.

The more raw interface is for building doing things around docker containers themselves, such as building containers to send to a registry, or running multi-container tests.

---
Originally reported by docwhat, imported from: Support common user stories for docker in builds

• status: Open
  
• priority: Major
  
• component(s): docker-workflow-plugin
  
• label(s): docker, pipeline, usability
  
• resolution: Unresolved
  
• votes: 0
  
• watchers: 2
  
• imported: 2025-12-07
  

Having been working with developers using the Pipelines and docker containers, I'm seeing several user stories evolve:




	
As a developer, I'm trying to build my code in CI using a container, so that my software builds the same everytime.

	
As a developer, I'm trying to build my container in CI, so that my code is properly packaged and can be safely deployed.

	
As a developer, I'm trying to run functional/integration tests in CI using containers, so I can ensure my code will work in production.

	
As a devops engineer, I'm running arbitrary tasks in a container, so that tasks happen at appropriate times with respect to CI builds.



Some of these tasks require that the default WORKSPACE and USER is used in the container.  Other tasks, like building source code, may require that /etc/passwd and /etc/group are updated with the Jenkins user and group.


I would propose that we break the docker pipeline interface up into two parts:




	
A raw wrapper around docker with some simple conveniences that won't interfere with doing any docker command desired.  This interface will not set environment variables, WORKSPACE or USER.

	
A simplified interface that can accept an optional Dockerfile, automatically updates the /etc/passwd and /etc/group and puts the workspace in a single known location, like /build.



The simplified interface would be designed for the first user story above.  The reason to use /build for the workspace is to prevent running into path names that are too long.  The /etc/passwd and /etc/group is to ensure various build commands (some linker commands, go get, and some python and ruby} commands, especially test cases) will work, yet let us also ensure files written to {{/build are owned by the correct user/group.


The more raw interface is for building doing things around docker containers themselves, such as building containers to send to a registry, or running multi-container tests.