-
New Feature
-
Resolution: Unresolved
-
Major
-
None
The Docker Custom Build Environment Plugin runs Docker Containers with a bunch of configuration parameters which seem to be hardcoded or discovered automatically from the slave's environment.
This leads to errors on running containers. Resp. it requires the Docker image to be built especially for those configurations which on the other hand would make it less portable and therefor breaks one of the most important advantages of Docker.
For example:
- Jenkins slave is running as user Jenkins on the Docker host those User-ID is 1001. To avoid permission errors we have to configure a user with ID 1001 in the image/container as well. What if we use this image on a Docker host where the Jenkins user has ID 1002?
- The PATH environment variable on the host is set to /usr/local/bin:/usr/bin. In the container which emulates another Distro it should also list /bin.
- The container has to run a service in the background (e.g. Xvfb to perform UI tests) but is hardcoded initialized running /bin/cat instead of a custom initialization command/script.
- The container's temporary directory /tmp is always mapped as volume to the host's temporary directory /tmp which may lead to errors running multiple containers creating their own but equally named temporary files (e.g. running Xvfb on display 99 inside a container).
[JENKINS-29390] Parameterization for Docker Container configuration.
- Jenkins slave is running as user Jenkins on the Docker host those User-ID is 1001. To avoid permission errors we have to configure a user with ID 1001 in the image/container as well.
Please give more details on the permission errors you get, you should not need to create such a user in your image
- The PATH environment variable on the host is set to /usr/local/bin:/usr/bin. In the container which emulates another Distro it should also list /bin.
Need to investigate further but PATH should not be set based on host environment.
- The container has to run a service in the background (e.g. Xvfb to perform UI tests) but is hardcoded initialized running /bin/cat instead of a custom initialization command/script.
Such a container should rely on an entrypoint to run such background processes, then run the command.
- The container's temporary directory /tmp is always mapped as volume to the host's temporary directory /tmp which may lead to errors running multiple containers creating their own but equally named temporary files (e.g. running Xvfb on display 99 inside a container).
As explained this is a requirement for shell script build step support.
With later release you can configure user group for commands executed in container, this should help to address permission issues
You also can configure the startup command, so can run background tasks before you run a never ending command (I recommend `/bin/cat`)
Can we also make a similar consideration for volumes? I would like the volumes mounted for workspace and target paths to be configurable.
The current (default) is great for most cases but there are areas where it falls apart, namely places where the same directories are used by the job running inside the container and are also mounted.
For example, JENKINS_HOME is mounted inside the container, but I have an RPM that is building/installing a RPM that is creating those directories (the jenkins rpm), so in this case I would like the JENKINS_HOME to not match the paths in the rpm.
In a sense, in some instances I want the file system to be completely isolated from the host machine.
I'm thinking it would be nice if under 'volumes' the default was to have the ones that are currently hardcoded, but to allow the volumes to be completely configurable.
I'm curious to your thoughts on that, if you are open to it I may be able to throw a PR together that adds that support. If you want I can open a separate issue to discuss configurable volumes, just let me know.
Looking into the code it turns out that sharing of /tmp is necessary for execution of Shell Execution Build Steps which makes sense. So disabling sharing of /tmp maybe is not an option.