No information for the plugin 'cloudbees-docker-custom-build-environment' is available. It may have been removed from distribution.
This plugin allows to define the environment for your build using a Docker container.
As a developer, you don't like spending hours to setup project prerequisites (install java, maven, ruby, node, bundler, bower ...) so use a Dockerfile to define the reference build environment. Such a Dockerfile is committed to project SCM so it can benefit to others. Why then would you need to configure ToolInstallers on your CI server ?
This plugin let you define build environment as a docker container or Dockerfile. The full build will be executed inside such a container, in a controlled, well established, isolated, reproducible environment.
This plugin let you define a Docker container to host the build. Container will be built and ran for the duration of the project execution then deleted. As a result you get a clean build environment for each project run.
You can :
- Select the Docker image to run the build as a Docker image to be pulled. This is comparable to docker-plugin approach to offer jenkins-docker-slaves, but without any prerequisites on the Docker image nor need for Administrator privileges to configure the adequate slave template.
- Configure the plugin to build a container image from a Dockerfile stored in project repository. With this setup, you get both the project source code and build environment defined in SCM.
The build slave(s) running jobs need docker installed and daemon running. We suggest you use a "docker" label for such slaves, so you benefit jenkins slave management and Cloud capabilities
Initial release as "CloudBees Docker Custom Build Environment Plugin".
The docker container is ran after SCM has been checked-out into slave workspace, then all later build commands are executed within the container thanks to docker exec introduced in Docker 1.3. When configured to build container from Dockerfile, the plugin compute Dockerfile checksum and use it as container ID, so it can detect the image exists on slave and build it first time requested.
Compared to docker plugin,
- this plugin can use arbitrary docker image, there is NO prerequisite to get a specific user set, ssh daemon, or even JDK available in docker container you use for the build - no need for CI-specific docker image, can use the exact same docker image you use on developer workstation to run/test your project.
- change to the project that require new tools / version upgrades can be reflected in the Dockerfile within an atomic commit. No need to reconfigure the job or wait for the adequate slave to be setup. Can also use a distinct Dockerfile per project branch.
- user don't need Administrator privileges to setup a docker-slave template, just need to commit a Dockerfile
- docker-plugin abuse jenkins Cloud API. i.e. you have to define a fixed IP address and can't benefit a Cloud slave provider, or a pool of generic slaves. oki-docki will rely on slaves which have docker installed, and Jenkins will provision/pick-up available ones using all available slaves provider plugins.