How to enable scl in PodTemplate with maven and nodejs ? #582
Comments
|
You would need to construct an image that actually contains the nodejs+maven binaries. The inherit from you did is just for the slave pod configuration, it has no effect on the actual image you're running. So you would need to extend the maven image and add all the nodejs packages, or vice versa. And you'd need to make sure the scl enablement script[1] included in the image enabled both the nodejs and maven packages [1] https://github.com/openshift/jenkins/blob/master/slave-maven/contrib/bin/scl_enable |
|
Thanks for your reply @bparees I know the inherit I did is for the pod configuration, my intent was actually to inherit either from IMHO, it seems to be a good idea to reuse containers instead of rebuilding new one that are actually combinations of these. Except if you tell me it's a terrible idea to use sidecar containers to run jenkins pipeline for reasons I'm not aware of, I think we should support it, shouldn't we ? The only blocking point for that is the scl enablement which is as far as I know, specific to centos/rhel image. |
|
Sure, prefix your commands with the appropriate Scl enable statement would
be the most obvious solution.
Ben Parees | OpenShift
…On Sun, Apr 22, 2018, 13:55 Arnaud Deprez ***@***.***> wrote:
Thanks for your reply @bparees <https://github.com/bparees>
I know the inherit I did is for the pod configuration, my intent was
actually to inherit either from maven and add node as a sidecar container
like the multi-container example
<https://github.com/jenkinsci/kubernetes-plugin/blob/master/examples/multi-container.groovy>
shown in kubernetes-plugin, so it can also simplify the maintenance as we
can reuse these 2 containers (alone, together or with other containers if
needed).
IMHO, it seems to be a good idea to reuse containers instead of rebuilding
new one that are actually combinations of these.
Except if you tell me it's a terrible idea to use sidecar containers to
run jenkins pipeline for reasons I'm not aware of, I think we should
support it, shouldn't we ?
The only blocking point for that is the scl enablement which is as far as
I know, specific to centos/rhel image.
Is there still not a way to enable the scl on sidecar container ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#582 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEvl3h1ocjf7o4SvyVENOHGiYTLh3q8Jks5trMQngaJpZM4Teyhm>
.
|
|
Sure it works, but this is not convenient as I have to do it for each commands (see below): pipeline {
agent none
stages {
stage('test maven-nodejs') {
agent { label 'maven-nodejs' }
steps {
echo 'Hello from maven-nodejs slave'
sh 'mvn -version'
sh 'gradle -version'
container('nodejs') {
echo 'In container nodejs...'
sh 'source /usr/local/bin/scl_enable && node --version'
sh 'source /usr/local/bin/scl_enable && npm --version'
}
}
}
}
}Also, it prints some warnings for each commands: Isn't it a better way ? |
|
Sorry, I don't think it is not possible. The mechanism the kubernetes plugin uses to invoke the commands in the sidecar container does not give us a way to ensure the scl packages are enabled within that execution context, that I am aware of. We are only able to control the scl enablement within the primary container. The plugin effectively execs into the sidecar container, so the scl environment the image normally sets up is not going to be available and i don't see a way for us to control that behavior. If manual scl enablement of the commands are a problem for you, I suggest you build your own nodejs image using a different nodejs packaging. |
|
Ok, thank you a lot for your support! |
|
Hi, FYI, we've found a way to solve it by adding this line in #/bin/bash
echo "source /usr/local/bin/scl_enable" >> /tmp/.bashrcExplanations: //...
container('nodejs')
sh "env"
sh "node --version"
}By inspecting the env variables, it appears it also set the It might be interesting to at least document it and why not putting this by default in each slave/agent image so users can compose them. WDYT @bparees @gabemontero ? |
|
I don't work on this repo, but for the projects that I work on, we've got our own images based on the structure of the ones in this repo. We've done the following, which might be of use, if I understand the scenario correctly! In the Then in images that are based on that one, we extend the collections listed in that variable like this. |
|
I would have expected this: to accomplish the same thing as creating a if you want to make it look more like what @grdryn suggested for flexibility/extension that would be ok too. |
|
@bparees Ok, I will send a PR for that. @bparees the problem in the image is that it unset these variables https://github.com/openshift/jenkins/blob/master/agent-nodejs-8/contrib/bin/scl_enable#L2 so when I'm entering in a new bash, it does not source this. That's why I needed to create the file I'm not sure images from @grdryn can be used in sidecar container, isn't it ? I like the idea of @grdryn to define the scl in an environment variable so users can just inherit these images and eventually append some other scl to that variable. Stay tuned :-) |
|
Hi, Just to give a feed back, it seems our trick worked in So I will give up with this Thanks for your help. |
|
@bparees let me know if you think having my solution would be beneficial in your images. I'm not sure if it is or not, but happy to make a PR if so. |
|
@grdryn I think that's fairly similar to what we already do (though ours is less directly extensible): https://github.com/openshift/jenkins/blob/master/agent-nodejs-8/Dockerfile#L8-L10 I don't think directly invoking the scl_enable script in the configure-slave script would help in @arnaud-deprez's case since he's effectively exec'ing into the container so he gets a new shell environment where the configure-slave script has not been run. But if i've missed something and it would help, i'm certainly open to the PR. |
|
Yep @bparees got my point and I've look to your solution @grdryn and it is very close to what we currently have. I tried to use a mix of what we had and what you did @grdryn here: https://github.com/arnaud-deprez/jenkins/commit/c4180feb6271db478e1aa4488d817c003a334d46. The trick here https://github.com/arnaud-deprez/jenkins/blob/c4180feb6271db478e1aa4488d817c003a334d46/slave-base/contrib/bin/run-jnlp-client#L37-L42 did work with |
Hi,
For some of our projects, we are using JHipster.
The idea is to embedded a
Angularapplication into aspring-bootfat jar.To build this, we need first to build the
Angularapplication and then build thespring-bootwith the result of the former build.So basically I need capabilities of
mavenandnodejsjenkins slave.So my idea was to create a PodTemplate config that inherit from maven and add a nodejs container such as:
Then I tried that setup with this pipeline:
pipeline { agent none stages { stage('test maven-nodejs') { agent { label 'maven-nodejs' } steps { echo 'Hello from maven-nodejs slave' sh 'mvn -version' sh 'gradle -version' script { container('nodejs') { echo 'In container nodejs...' sh 'node --version' sh 'npm --version' } } } } } }But it fails with:
For some reason, it seems it does not source
/usr/local/bin/scl_enablein the second container.Any idea how to solve that ?
Thanks,
The text was updated successfully, but these errors were encountered: