Aug 05, 2022 7:42:34 AM hudson.remoting.jnlp.Main createEngine
INFO: Setting up agent: jenkins-jdk8-186dbdbe03e
Aug 05, 2022 7:42:34 AM hudson.remoting.jnlp.Main$CuiListener <init>
INFO: Jenkins agent is running in headless mode.
Aug 05, 2022 7:42:34 AM hudson.remoting.Engine startEngine
INFO: Using Remoting version: 4.13
Aug 05, 2022 7:42:34 AM hudson.remoting.Engine startEngine
WARNING: No Working Directory. Using the legacy JAR Cache location: /home/jenkins/.jenkins/cache/jars
Aug 05, 2022 7:42:35 AM hudson.remoting.jnlp.Main$CuiListener status
INFO: WebSocket connection open
Aug 05, 2022 7:42:35 AM hudson.remoting.jnlp.Main$CuiListener status
INFO: Connected
Aug 05, 2022 7:42:42 AM hudson.remoting.UserRequest perform
WARNING: LinkageError while performing UserRequest:org.jenkinsci.plugins.gitclient.Git$GitAPIMasterToSlaveFileCallable@169bca17
java.lang.UnsupportedClassVersionError: Failed to load org.jenkinsci.plugins.gitclient.verifier.AbstractJGitHostKeyVerifier
at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:460)
at hudson.remoting.RemoteClassLoader.loadRemoteClass(RemoteClassLoader.java:292)
at hudson.remoting.RemoteClassLoader.loadWithMultiClassLoader(RemoteClassLoader.java:269)
at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:228)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
at java.lang.Class.getDeclaredMethod(Class.java:2128)
at java.io.ObjectStreamClass.getPrivateMethod(ObjectStreamClass.java:1643)
at java.io.ObjectStreamClass.access$1700(ObjectStreamClass.java:79)
at java.io.ObjectStreamClass$3.run(ObjectStreamClass.java:520)
at java.io.ObjectStreamClass$3.run(ObjectStreamClass.java:494)
at java.security.AccessController.doPrivileged(Native Method)
at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:494)
at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:391)
at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:681)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1852)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1852)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2186)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1669)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2431)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2355)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2213)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1669)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2431)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2355)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2213)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1669)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:503)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:461)
at hudson.remoting.UserRequest.deserialize(UserRequest.java:289)
at hudson.remoting.UserRequest.perform(UserRequest.java:189)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:376)
at hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:121)
at java.lang.Thread.run(Thread.java:750)
Caused by: java.lang.UnsupportedClassVersionError: Failed to load com.trilead.ssh2.ServCaused by: java.lang.UnsupportedClassVersionError: Failed to load com.trilead.ssh2.ServerHostKeyVerifier
at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:460)
at hudson.remoting.RemoteClassLoader.loadRemoteClass(RemoteClassLoader.java:300)
at hudson.remoting.RemoteClassLoader.loadWithMultiClassLoader(RemoteClassLoader.java:269)
at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:228)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at java.lang.ClassLoader.defineClass(ClassLoader.java:635)
at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:458)
... 42 more
Caused by: java.lang.UnsupportedClassVersionError: com/trilead/ssh2/ServerHostKeyVerifier has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at java.lang.ClassLoader.defineClass(ClassLoader.java:635)
at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:458)
... 51 more
I am trying to compile a project with a pipeline using the docker agent with the image (maven:3.6.0-jdk-8-alpine). Jenkins is running inside a docker container itself (jenkins/jenkins:lts-jdk11). The pipeline fails in downloading the dependencies for my project. On the contrary, If I start a maven:3.6.0-jdk-8-alpine on the same host, compilation works fine. Is there something network related i should pay attention to with jenkins running inside a docker?
the pipeline is very basic:
pipeline {
agent { docker { image 'maven:3.6.0-jdk-8-alpine' } }
stages {
stage('Build') {
steps {
sh "apk add git"
git 'https://github.com/eea/geonetwork-eea.git'
sh 'mvn clean install -U -DskipTests'
sh 'cd web'
sh "mvn clean install -U -DskipTests -Des.host=elasticsearch -Dkb.url=http://kibana:5601;"
}
}
}
}
this result into:
[ERROR] Failed to execute goal on project cachingxslt: Could not resolve dependencies for project org.geonetwork-opensource:cachingxslt:jar:2.9.0-SNAPSHOT: Failed to collect dependencies at net.sf.saxon:saxon:jar:9.1.0.8b-patch: Failed to read artifact descriptor for net.sf.saxon:saxon:jar:9.1.0.8b-patch: Could not transfer artifact net.sf.saxon:saxon:pom:9.1.0.8b-patch from/to k-int (http://developer.k-int.com/maven2/): Connect to developer.k-int.com:80 [developer.k-int.com/62.31.135.44] failed: Connection refused (Connection refused) -> [Help 1]
Hey all, this may very well be a FAQ, but we've been running the jenkinsci/blueocean docker image for a few years now, but it seems like jenkins/jenkins is what we should be running? Has anyone switched? Is it as simple as changing the image name in the docker-compose file? If anyone has any experience, or knows of a page I can read about this, that would be great. If not, I'll figure it out.
should hopefully just be a matter of switching the image
The
jenkinsci/blueocean Docker images are deprecated. They were used in the past for tutorials on jenkins.io. Those tutorial references were replaced by references to the jenkins/jenkins docker containers in October 2020. Switch the FROM argument and assure that you install the plugins you need for your installation.
Hi! I've deployed Jenkins in a EKS kluster on AWS. I've a windows nodegroup in the cluster as well where I'm trying to run some windows containers. My template is using "jenkins/inbound-agent:windowsservercore-ltsc2019" which it pulls just fine and spins up. But it also tries to spin up another image after the first container is started, "jenkins/inbound-agent:4.11-1-jdk11". It fails because "no matching manifest for windows/amd64 10.0.17763 in the manifest list entries". My EC2 nodes are running the following ami: Windows_Server-2019-English-Full-EKS_Optimized-1.22-2022.08.09 ami-02a30b67f82cdda7a. Am I understanding it correctly that I'm using a not-supported version of windows?
your version of windows should be supported fine
hi , i have installed jenkins on docker, need to ask what is the best practice to use plugins.txt to install plugins .Due to some reasons we are using jdk8 image . So will it create any issue if use plugins with latest tag (ws-cleanup:0.42 or ws-cleanup:latest) ? or should i use versioned plugins in plugins.txt. and how plugins are handled in jenkins according to their jdk . Can using latest plugins cause issue for jenkins on jdk8 centos image.
Sam Martin: there is a nice official documentation at https://www.jenkins.io/doc/book/managing/nodes/ to get started. Then it depends on your infrastructure:
- If you use a Cloud system which has an associated Jenkins plugin, then you should use it (such as "Amazon EC2", "Azure VM", "Azure ACI", "Openstack", etc.). Jenkins would create build agent programattically.
- If you use a system that is code managed (Using Terraforma, Ansible, Puppet, whatever infra as code tool), then you might want to manage programmatically the VMs and use "Jenkins Configuration as Code" plugin to define a permanent build agent using a YAML definition
Sam Martin: Please note that:
- Executing builds on the Jenkins controller is a bad practise: it means that your build can access all the Jenkins credentials and controller Jenkins home
- It is strongly recommended to create a build agent to execute build. There is no problem to have this build agent executing with JDK11 (same as Jenkins's controller JDK), but providing a default JDK8 through the environement variables "JAVA_HOME'" and "PATH"
our requirement is, as soon as the Jenkins container is up we want to make the docker engine host machine as its slave automatically .
3 replies
good, then docker-compose can easily be used. I got a working example here: https://github.com/dduportal/jenkins-examples/blob/main/docker/docker-compose.yml#L15. Fundamentals are:
- Declare a container that will act as "permanent agent". The Docker image of this agent should contain both JDK11 (like your Jenkins controller) and the JDK8 you need for your builds set as default, and also SSH server.
- Configuration of the agent on the controller is done using Jenkins config as code: https://github.com/dduportal/jenkins-examples/blob/8f0bc983389038d90a2b61bed571105069e5c162/docker/casc.d/agents.yaml#L2-L16
- About the credentials: Generate an SSH key pair (like in my repository) and mount it like I did in
/run/secretes(ref. https://github.com/dduportal/jenkins-examples/blob/8f0bc983389038d90a2b61bed571105069e5c162/docker/docker-compose.yml#L8-L9
) so that JCasC can get the credential in a safe way through a variable (as per the official doc - https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/docs/features/secrets.adoc#docker-secrets)- Then credential can be declared in the controller to programmatically load the private key: https://github.com/dduportal/jenkins-examples/blob/8f0bc983389038d90a2b61bed571105069e5c162/docker/casc.d/credentials.yaml#L12
1 reply
hi , casc is failing for docker compose but working with docker run , Can anyone please help here !
getting this error:
second | 2022-08-26 21:36:14.111+0000 [id=30] SEVERE jenkins.InitReactorRunner$1#onTaskFailed: Failed ConfigurationAsCode.init
second | io.jenkins.plugins.casc.ConfiguratorException: Invalid configuration: '/var/jenkins_home/casc.yaml' isn't a valid path.
getting this error:
second | 2022-08-26 21:36:14.111+0000 [id=30] SEVERE jenkins.InitReactorRunner$1#onTaskFailed: Failed ConfigurationAsCode.init
second | io.jenkins.plugins.casc.ConfiguratorException: Invalid configuration: '/var/jenkins_home/casc.yaml' isn't a valid path.
4 replies
are you sure? cause its saying its not there, I would try running
docker-compose run jenkins ls -l /var/jenkins/home to confirm. Also this channel is for creating the jenkins packaging, not for jenkins help, I would recommend going to jenkinsci/jenkins room
@cccarv82: jenkins docker image doesn't have docker cli. You'll have to extend the image, or use an agent outside of your controller (recommended)
I am trying to upgrade few plugins because their older versions are causing dependencies issue, however when add them using plugin manager jar, they dont get updated in Kubernetes container, however they are in my image
Hi team.. I'm working with a project that uses espressif and to build it on my machine with docker way I do the following:
docker run --rm -v $PWD:/project -w /project espressif/idf:v4.2.2 idf.py build (note that, first of all I make a cd to the project directory and then the PWD environment variable passes the correct path for mounting the volume)
I would like to elaborate a declarative pipeline, and I would like to execute the command equivalent to the one above. The way I implemented it based on other examples that worked, and the log result below.
I don't understand why the way to pass these 'idf.py build' arguments in the 'steps' block is not working. Does anyone have any ideas?
My pipeline:
pipeline {
agent any
environment {
PROJ_NAME = 'test'
}
stages {
stage('Checkout') {
steps {
git url: 'ssh://git@bitbucket.org/joaogbc/iot-project.git'
}
}
stage('Build') {
agent {
docker {
image 'espressif/idf:v4.2.2'
args '--rm -v $PWD:/project -w /project'
reuseNode true
}
}
steps{
sh 'idf.py build'
}
}
}
}Error snippet:
[Pipeline] withDockerContainer
Jenkins does not seem to be running inside a container
$ docker run -t -d -u 1000:1000 --rm -v $PWD:/project -w /project -w /var/lib/jenkins/workspace/iot-project-TEST -v /var/lib/jenkins/workspace/iot-project-TEST:/var/lib/jenkins/workspace/iot-project-TEST:rw,z -v /var/lib/jenkins/workspace/iot-project-TEST@tmp:/var/lib/jenkins/workspace/iot-project-TEST@tmp:rw,z -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** espressif/idf:v4.2.2 cat
$ docker top 81920a1146eabe9bf5c08339a682d81ac23777de0421895e1184d2a8ef27fc8c -eo pid,comm
ERROR: The container started but didn't run the expected command. Please double check your ENTRYPOINT does execute the command passed as docker run argument, as required by official docker images (see https://github.com/docker-library/official-images#consistency for entrypoint consistency requirements).
Alternatively you can force image entrypoint to be disabled by adding option `--entrypoint=''`.
[Pipeline] {
[Pipeline] sh
+ idf.py build
/var/lib/jenkins/workspace/iot-project-TEST@tmp/durable-b8bf6ce0/script.sh: 1: /var/lib/jenkins/workspace/iot-project-TEST@tmp/durable-b8bf6ce0/script.sh: idf.py: not found
[Pipeline] }
$ docker stop --time=1 81920a1146eabe9bf5c08339a682d81ac23777de0421895e1184d2a8ef27fc8c
$ docker rm -f 81920a1146eabe9bf5c08339a682d81ac23777de0421895e1184d2a8ef27fc8c
[Pipeline] // withDockerContainer
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
ERROR: script returned exit code 127
Finished: FAILURE
I've already managed to successfully headless-build with the eclipse image as follows:
stage('Build') {
agent {
docker {
image 'tool/stm32-cubeide-image:1.0'
reuseNode true
}
}
steps {
sh '/opt/stm32cubeide/headless-build.sh -importAll $WORKSPACE -data $WORKSPACE -cleanBuild $DIR/$OPT_BUILD'
}
}
@timja: I'm not sure to understand why is jenkinsci/docker#1456 a docker (image) issue? If I understand correctly, it's the
jenkins-plugin-cli which fails the plugin installation?
@timja: i thought we got rid of the shell script
install-plugins.sh (which was using the versionLT() bash function as far as I remember) ?
7 replies
yes but plugins aren't in the image outside of the volume and then there's a script here that copies them:
https://github.com/jenkinsci/docker/blob/00d1edcbf6e0bd78ff5b359731310b91bdac9b07/jenkins-support#L42
https://github.com/jenkinsci/docker/blob/00d1edcbf6e0bd78ff5b359731310b91bdac9b07/jenkins-support#L42
oh I see, it's the "copy plugins at startup" script. Thanks for the explanation!
its kinda a jenkins core + docker issue. install plugin ci puts it in jenkins ref, and jenkins core only copies ref if the file doesn't exist.
oh my bad, not core, is purely docker?
Hi all, ive made a docker-compose.yml and Dockerfile for jenkins with the hope that I'll be able to locally test jobs and have it all automated so i don't need the web UI ... not immediately apparent is the best way to go about automation of creating jobs. Ive been trying to use jenkins-cli and a little bit hung up on auth ... or should i just place files in the right places in jenkins_home? Any advice is greatly appreciated :)
another thing i'd like to do is just pass the admin password as a build arg ( or better way? )
have it all automated
Use https://www.jenkins.io/projects/jcasc/ with job-dsl-plugin: https://github.com/jenkinsci/job-dsl-plugin/blob/master/docs/JCasC.md :)