Closed lhupfeldt closed 6 months ago
I never tried that, can I ask you the use case of having 2 different casc config?
Sorry for the delay. The use case is basically "separation of concerns". We have two pipeline libraries, each having it's own piece of configuration. But I think the main point is that jcasc setup supported by plain Jenkins should be supported with the operator. It seems the operator does it't own handling of the jcasc. I'm curious why it does not simply mount the configmap in the jenkins namespace and ask jenkins to do the load?
It seems the operator does it't own handling of the jcasc. I'm curious why it does not simply mount the configmap in the jenkins namespace and ask jenkins to do the load?
Because afaik if you change the casc in the configmap jenkins will read it only when it start the process. The operator is constantly trying to update the CASC that you have as code in your git repo, this will let "live" changes of the CASC (obv you can do it manually from the webui in a imperative way).
Honestly I don't think that supporting a separated casc is a priority or something we need atm, sorry
(but I'm open to review any PRs that will address that!)
We are having an issue with casc files not being merged the same way they are on a non kubernetes/operator setup.
Given the following configmap (unrelated parts removed):
What we see is: Only a single library is defined in Jenkins. The second library casc file overwrites the first one. There are no errors logged from the casc file processing.
Kubernetes version: v1.24.15+rke2r1 Jenkins Operator version: v0.8.0-beta2
With the lirary definitions in separate casc files on non-kubernete Jenkins both libraries will be defined. I.e. The (one element) list in the second file is appended to the list from the first file.
Can you explain how the casc processing is done with the operator? I see that the log output is in the operator log, not the Jenkins log as I would have expected. I would have expected that the configmap files were mounted in the Jenkins container, but that does not seem to be the case.