@ScottAShipp_twitter you can define Jenkins configuration with the Docker image in several different ways.
For example, files in the ref directory of the image you define (based on the jenkins/jenkins) will be placed into the working Jenkins image. I used that technique to store job configuration XML files, credential files, and more. Works great. I install plugins that way using a git large file storage repository. Records the exact versions of plugins I'm using without requiring that I insert their version numbers into a configuration file.
You can define the exact version of plugins you want and call the plugin install script as described at https://github.com/jenkinsci/docker/blob/master/README.md#preinstalling-plugins .
If you'd like to see a sample, refer to https://github.com/MarkEWaite/docker-lfs/tree/lts-with-plugins
You can use the configuration as code plugin and define your Jenkins configuration with a YAMLfile in the Docker image
I will dig in to documentation on that ref feature
@ScottAShipp_twitter the configuration for those items is most likely supported by the Configuration as Code plugin so that you can express the configuration in an easy to read YAML format rather than storing XML conifguration files. However, there are still some plugins that don't support configuration as code plugin. In those cases, storing the XML files in the ref directory works just fine.
New question for you all. Is it better to use jenkins/jenkins and install Blue Ocean plugins separately, or to use the jenkinsci/blueocean as a base
Both seem to have documentation which says "this is the recommended Docker image to use for Jenkins"
or similar
We hope to eventually rework the tutorials to not require Docker in Docker, but it is so convenient to run a Python docker image or a NodeJS Docker image from the tutorial environment. Production users don't usually need the same simplicity (single computer, low compute use, etc.) that a tutorial user needs
We started with jenkins/jenkins, but when reading https://www.jenkins.io/doc/book/installing/#downloading-and-running-jenkins-in-docker it very strongly and confidently suggests only using the jenkinsci/blueocean image. "There are several Docker images of Jenkins available. The recommended Docker image to use is the jenkinsci/blueocean image (from the Docker Hub repository)"
I wonder if that should be updated. It doesn't mention tutorials
That is a good one for next week's user experience Hackfest. Docs are part of the user experience...
Hi, is it possible to run
The argument is without
By default the image is put at the end of command during job run and looks like this:
docker.image('maxys/docusaurus-pdf:latest').withRun ("from-build --no-sandbox -v /var/jenkins_home/workspace/docs:/workspace -o /workspace/build/internal.pdf /workspace/build docs/Docusaurus/DocusaurusGetStarted docs") in any way?The argument is without
- or -- and when I do it the way above Jenkins try to pull 'customArgument' image.By default the image is put at the end of command during job run and looks like this:
docker run -d from-build --no-sandbox -o build/img/internal.pdf build docs/Docusaurus/DocusaurusGetStarted docs maxys/docusaurus-pdf:latest
Unable to find image 'from-build:latest' locally
docker: Error response from daemon: pull access denied for from-build, repository does not exist or may require 'docker login': denied: requested access to the resource is denied.
Hi @fasolens, you probably want the normal https://gitter.im/jenkinsci/jenkins channel is more geared towards using the docker containers that Jenkins provides
Hello All, good afternoon to you. I'm looking for a little help to better understand the docker jenkins/inbound-agent image. I've lots of jobs that need tools installing on the inbound-agent. I'd like to check my understanding is correct and that if i wish to install build tools on to the agent I'll need to make my own docker file and then install via apt-get or yum. Sorry I'm not actually clear what o/s the agent is running.
Second part of the question... If i try and start the jenkins/inbound-agent locally on my laptop, with a view to then login via docker exec interactive bash shell etc etc. I can't because the image won't actually start unless it can connect to a jenkins master. Is there any way around this to allow me to test my build tools?
Second part of the question... If i try and start the jenkins/inbound-agent locally on my laptop, with a view to then login via docker exec interactive bash shell etc etc. I can't because the image won't actually start unless it can connect to a jenkins master. Is there any way around this to allow me to test my build tools?
Thanks for replying Alex, currently if i use docker run --init jenkins/inbound-agent
without the docker run --init jenkins/inbound-agent -url http://jenkins-server:port <secret> <agent name> set it just moans that it expects these values to be set.
if I set them to fake details because I don't have a local master etc, so something like
docker run --init jenkins/inbound-agent -url http://jenkins-server:80 mypass mylocalagent
the docker images fires up fails to connect to the master and terminates.
without the docker run --init jenkins/inbound-agent -url http://jenkins-server:port <secret> <agent name> set it just moans that it expects these values to be set.
if I set them to fake details because I don't have a local master etc, so something like
docker run --init jenkins/inbound-agent -url http://jenkins-server:80 mypass mylocalagent
the docker images fires up fails to connect to the master and terminates.
any way to start it and not try and connect, fail and then terminate
something like that ^^
Thought that was the standard jenkins image.
There is a
slimvariant that uses Debian slim and an Alpine variant for those who prefer Alpine
Including uucp?
The goal of the Docker image is to provide a working environment for many uses cases, not to provide the minimum distribution that will allow Jenkins to start. Jenkins will start without installing command line git and without installing git-lfs, but users have preferred a working environment over a minimal environment. The
alpine tag is more likely what you want if you're seeking a minimal environment
At that point you can layer whatever distro you like.
Layering the distro on top of jenkins solves them with a single jenkins distro: slap anything you like on it: Arch, Gentoo, Debian, RH... or a subset that doesn't include pieces with security issues that prevent using it in the first place because the distros include problematic executables.