-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
jenkins 2.166
kubernetes: 1.14.2
kubernetes-pipeline: 1.5
Our jenkins instance has a kubernetes pod template that's defined as the defaults provider, named `jenkins slave`
`jenkins slave` contains single jnlp container template with a docker image defined, also containing working directory and the jnlp args ${computer.jnlpmac} ${computer.name} plus resource allocations and some environment variables
In my pipeline i have a kube-slave.yml defined that gets loaded with
agent {
kubernetes {
cloud 'jenkins-jenkins'
label label()
defaultContainer 'jnlp'
yamlFile 'kube-slave.yaml'
}
}
A sample of the yaml file is attached.
And the yaml file overrides the `jnlp` container with one that has a different image and resource requirements. However when the plugin attempts to combine the two templates, i end up with Combined parent + template where the override's name and env vars among other things are the overridden values, but the container itself its resource limits are the ones that were defined in the default provider.
[JENKINS-56416] Unable to override global config pod template in pipeline
I believe I am having the same issue:
I cannot override the defaultsProviderTemplate jnlp container with calling a podTemplate() from a pipeline that uses yaml for the pod description.
only with containerTemplate() inside the podTemplate() call it is possible to use a different jnlp container than what is defined in the defaultProviderTemplate.
Following the plugin logs with logging level "finest",
at the beginning, every thing seems fine, until this call:
That combine call, seems to invert the parameters:
the template becomes the "Parent" and the "defaultsProviderTemplate" becomes the child,
which might explain why in the combined pod the container of the "defaultsProviderTemplate" was taken and not the one from the template..
Yacine
added a comment - - edited I believe I am having the same issue:
I cannot override the defaultsProviderTemplate jnlp container with calling a podTemplate() from a pipeline that uses yaml for the pod description.
only with containerTemplate() inside the podTemplate() call it is possible to use a different jnlp container than what is defined in the defaultProviderTemplate.
Following the plugin logs with logging level "finest",
at the beginning, every thing seems fine, until this call:
https://github.com/jenkinsci/kubernetes-plugin/blob/74906a1293fa1fb87989bd2caf4012afdb497edc/src/main/java/org/csanchez/jenkins/plugins/kubernetes/PodTemplateBuilder.java#L257
That combine call, seems to invert the parameters:
the template becomes the "Parent" and the "defaultsProviderTemplate" becomes the child,
which might explain why in the combined pod the container of the "defaultsProviderTemplate" was taken and not the one from the template..
iocanel, vlatombe, looks like a bug?
template.getYamlsPod() is a parent? I think it's should be a child. so that, template definition could overide the parent/gobal default
src/main/java/org/csanchez/jenkins/plugins/kubernetes/PodTemplateBuilder.java line228: Pod pod = combine(template.getYamlsPod(), builder.endSpec().build()); src/main/java/org/csanchez/jenkins/plugins/kubernetes/PodTemplateUtils.java /** * Combines a Pod with its parent. * @param parent The parent Pod (nullable). * @param template The child Pod */ public static Pod combine(Pod parent, Pod template) {