Open TueDissingWork opened 1 year ago
No we do not have atm a way to avoid the plugin installation.
But it's something that should be implement to have jenkins images with pre-installed plugins to avoid network issues and airgapped contexts.
So yes I have in mind to add that support but not soon, around version 0.10
No we do not have atm a way to avoid the plugin installation.
But it's something that should be implement to have jenkins images with pre-installed plugins to avoid network issues and airgapped contexts.
So yes I have in mind to add that support but not soon, around version 0.10
Great to hear that this is on the roadmap. Is there a task for this feature already and a preferred way/place to implement this? It could be a nice task to look further into during the summer.
Is there a task for this feature already and a preferred way/place to implement this? It could be a nice task to look further into during the summer.
sorry I'm reading this only now, the way I'm thinking is:
Personally, this is a major issue.
Whenever there is maintenance in my k8s cluster and jenkins redeploys - apparently jenkins plugins change dependencies and things break. Constantly.
I have to frequently bump dependencies of my user plugins since they decide to become incompatible with the versions i specified. It's highly annoying for developers when jenkins goes down every few days due to plugin incompatibilities.
Maybe i am doing something wrong here, but it's a very painful issue. Being able to simply package a collection of plugins with my deployment and upgrade at my leisure and not when plugin dependencies fall apart would be ideal.
Being able to use a local plugin repository would also be a good idea.
https://github.com/jenkins-infra/helpdesk/issues/3930 we need to proper address this also because of this ^
Maybe i am doing something wrong here, but it's a very painful issue. Being able to simply package a collection of plugins with my deployment and upgrade at my leisure and not when plugin dependencies fall apart would be ideal.
you can try with latestPlugin
set to false
: https://github.com/jenkinsci/kubernetes-operator/blob/bfda3c8cf99fc56cb65519a673f3b8a6209deb0d/chart/jenkins-operator/templates/jenkins.yaml#L110 and https://github.com/jenkinsci/kubernetes-operator/issues/797
@brokenpip3 could it help somehow? What is the image used by the operator? (Sorry I don't really know how this plugin works, that might be completely off topic)
As noted by @MarkEWaite, building your image with plugins integrated in it is far better than downloading them for each new instance.
You can take a look at how we're doing it for our own controller image there for example: https://github.com/jenkins-infra/docker-jenkins-weekly/blob/main/Dockerfile
Originally posted by @lemeurherve in https://github.com/jenkins-infra/helpdesk/issues/3935#issuecomment-1931910057
Describe the bug When running in an air gapped environment, it isn't possible to install any plugins on demand. This is causing the startup of the Jenkins master to fail.
To Reproduce Run the jenkins master in an air gapped environment without access to the Internet.
Additional information
Kubernetes version: Tested on minikube version: v1.30.1 commit: 08896fd1dc362c097c925146c4a0d0dac715ace0
Jenkins Operator version: Image: virtuslab/jenkins-operator:v0.7.1
Is that any way to tell the operator not to touch the plugins? We will be adding all needed plugins (base and userspecific) within the used container image.