Following up on this discussion - my security issue was closed - opinion was its not jenkins problem its Debians problem :facepalm:
but I did some more testing regardless -
JDK11 - 2.267 - 13 Medium findings + 89 others (Debian Stretch based)
Alpine - 2.267 - no findings - container is clean
Centos (8) - 2.267 - no findings - Container is clean
Default jenkins/jenkins - 2.266 - 9 high - 17 medium - 37 low - 70 informational - (Deb stretch 9.13)
These results are all with AWS ECR scanning which uses Clair scan rules
How can I tell the Jenkins Kubernetes Plugin to not set any nodeSelector? I tried setting yamlMergeStrategy: override() and specifying in the yaml that nodeSelector: {} should make it an empty dict, but Jenkins still injects its additions. I can of course explicitly set the nodeSelector os, but setting it to something other than linux is only even worse, including "" or null, which still lead to it being created with the selector, just with an unfullfillable operating system selector.
Does anyone have an idea how I could specifically unset it, or force jenkins to not add stuff I don't want it to add?
I have a NAS with on which I run Jenkins docker image I made (it's an ARMv7 NAS and the provided images don't work on that platform) together with a few agent-docker-images, one for dotnet stuff and one for building docker images. This used to work, at least back in october. But I hadn't build for a while and now building docker images doesn't work anymore. There's been some updates to Jenkins and the NAS has its docker upgraded from 17.x to 19.x. I don't know what broke it, but one of these things seems likely. Firing up dotnet agents still works fine.
When I go to my docker agent setup, I see an error saying:
Bad Message 414
reason: URI Too Long
I found an article that said I should add "--requestHeaderSize=32768" to JENKINS_ARGS so I tried with
ENV JENKINS_ARGS="--requestHeaderSize=32768"
in the Dockerfile but it doesn't work. I also added "--httpPort=8999" expecting the website not to work anymore as that port isn't mapped, but it still works, so I think the variable isn't being read. Not sure though, as I don't really know how everything works.
I also see errors in the logfile that to me do not really seem like the same problem as "URI Too Long" but they seem to occur when it's trying to fire up a new agent. Not sure what to make of this.
Any suggestions how to fix this?
FROM jenkins/jenkins:2.263.1
COPY plugins_extra.txt /usr/share/jenkins/ref/plugins_extra.txt
ENV JENKINS_HOME /var/jenkins_home
(…)
ENV JAVA_OPTS "-Dhudson.model.Slave.workspaceRoot=w -Djenkins.CLI.disabled=true -Djenkins.install.runSetupWizard=false -Dorg.apache.commons.jelly.tags.fmt.timeZone=Europe/Stockholm ${JAVA_PROXY:-}"
RUN /usr/local/bin/install-plugins.sh < /usr/share/jenkins/ref/plugins_extra.txt/var/jenkins_home and I experience this problem on one machine (at work), but not on my laptop at home… it seems weird and I am not sure what to look for
docker-workflow-plugin for the past 48 hours and I can't seem to find a strategy that works for us. In past years, because of the lack of windows agent support, I've written two completely independent "docker-bindings" in shared libraries. I REALLY want to get back to using the official plugin, because we'll be sharing the library code with a user community and so we want it to be as "generic" as possible.
docker.inside() or docker.withRun() or withContainer that meets all of them. I'm hoping it's a lack of creativity or something on my part.
jenkins, and leverage the users home directory.
docker.inside, then we have to accept and workaround the fact that jenkins runs as jenkins, and sets the working directory to the workspace which is mounted back to master (and ALL the env vars). I understand that this behavior are fundamental to how the agent code runs in the container, but it's very surprising to me that there's no option or env var or something to give users some flexibility on running their commands here.