upgrade Kubernetes plugin to 1.28.6 break our pipeline flows - jenkins

Jenkins Master : 2.282
Kubernetes plugin 1.28.5
after upgrade Kubernetes to 1.28.6 version , we find out that part of our pipelines that use yaml from shared library
our shared library yaml
agent {
kubernetes {
cloud "kube-cloud"
inheritFrom 'jnlp-slave-terraform'
yaml libraryResource('k8s/tf.yaml')
}
}
the failed flows use initContainers in the yaml file.
I think this commit break it - [https://github.com/jenkinsci/kubernetes-plugin/pull/929
attached the error we got when trying to lunch new pods
Also: java.lang.Throwable: launched here
at hudson.slaves.SlaveComputer._connect(SlaveComputer.java:283)
at hudson.model.Computer.connect(Computer.java:435)
at hudson.slaves.CloudRetentionStrategy.start(CloudRetentionStrategy.java:73)
at org.jenkinsci.plugins.durabletask.executors.OnceRetentionStrategy.start(OnceRetentionStrategy.java:83)
at org.jenkinsci.plugins.durabletask.executors.OnceRetentionStrategy.start(OnceRetentionStrategy.java:46)
at hudson.model.AbstractCIBase.updateComputer(AbstractCIBase.java:161)
at hudson.model.AbstractCIBase.access$000(AbstractCIBase.java:43)
at hudson.model.AbstractCIBase$2.run(AbstractCIBase.java:223)
at hudson.model.Queue._withLock(Queue.java:1383)
at hudson.model.Queue.withLock(Queue.java:1260)
at hudson.model.AbstractCIBase.updateComputerList(AbstractCIBase.java:206)
at jenkins.model.Jenkins.updateComputerList(Jenkins.java:1632)
at jenkins.model.Nodes$2.run(Nodes.java:139)
at hudson.model.Queue._withLock(Queue.java:1383)
at hudson.model.Queue.withLock(Queue.java:1260)
at jenkins.model.Nodes.addNode(Nodes.java:135)
at jenkins.model.Jenkins.addNode(Jenkins.java:2155)
at hudson.slaves.NodeProvisioner.lambda$update$6(NodeProvisioner.java:256)
at hudson.model.Queue._withLock(Queue.java:1383)
at hudson.model.Queue.withLock(Queue.java:1260)
at hudson.slaves.NodeProvisioner.update(NodeProvisioner.java:225)
at hudson.slaves.NodeProvisioner.access$900(NodeProvisioner.java:64)
at hudson.slaves.NodeProvisioner$NodeProvisionerInvoker.doRun(NodeProvisioner.java:823)
at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:91)
at jenkins.security.ImpersonatingScheduledExecutorService$1.run(ImpersonatingScheduledExecutorService.java:67)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
created an issue as well
issues.jenkins.io/browse/JENKINS-65074

Related

Failed to initialize Jenkins

Any idea about this Error?
I'm getting this Error in Jenkins Pods startup in GKE Cluster:
Docker image used Latest from
NAME CREATED IMAGE
jenkins 2021-02-13T15:31:20Z jenkins/jenkins:lts
GKE Cluster:1.16.15-gke.6000
Node Pool Version:1.15.12-gke.20
Helm chart:https://github.com/helm/charts/tree/master/stable/jenkins
2021-02-13 15:36:26.958+0000 [id=27] SEVERE jenkins.InitReactorRunner$1#onTaskFailed: Failed ConfigurationAsCode.init
java.lang.IllegalArgumentException: No hudson.slaves.Cloud implementation found for kubernetes
at io.jenkins.plugins.casc.impl.configurators.HeteroDescribableConfigurator.lambda$lookupDescriptor$11(HeteroDescribableConfigurator.java:211)
at io.vavr.control.Option.orElse(Option.java:321)
at io.jenkins.plugins.casc.impl.configurators.HeteroDescribableConfigurator.lookupDescriptor(HeteroDescribableConfigurator.java:210)
at io.jenkins.plugins.casc.impl.configurators.HeteroDescribableConfigurator.lambda$configure$3(HeteroDescribableConfigurator.java:84)
at io.vavr.Tuple2.apply(Tuple2.java:238)
at io.jenkins.plugins.casc.impl.configurators.HeteroDescribableConfigurator.configure(HeteroDescribableConfigurator.java:83)
at io.jenkins.plugins.casc.impl.configurators.HeteroDescribableConfigurator.check(HeteroDescribableConfigurator.java:92)
at io.jenkins.plugins.casc.impl.configurators.HeteroDescribableConfigurator.check(HeteroDescribableConfigurator.java:55)
at io.jenkins.plugins.casc.BaseConfigurator.configure(BaseConfigurator.java:344)
at io.jenkins.plugins.casc.BaseConfigurator.check(BaseConfigurator.java:287)
at io.jenkins.plugins.casc.ConfigurationAsCode.lambda$checkWith$8(ConfigurationAsCode.java:753)
at io.jenkins.plugins.casc.ConfigurationAsCode.invokeWith(ConfigurationAsCode.java:689)
at io.jenkins.plugins.casc.ConfigurationAsCode.checkWith(ConfigurationAsCode.java:753)
at io.jenkins.plugins.casc.ConfigurationAsCode.configureWith(ConfigurationAsCode.java:738)
at io.jenkins.plugins.casc.ConfigurationAsCode.configureWith(ConfigurationAsCode.java:614)
at io.jenkins.plugins.casc.ConfigurationAsCode.configure(ConfigurationAsCode.java:298)
at io.jenkins.plugins.casc.ConfigurationAsCode.init(ConfigurationAsCode.java:290)
Caused: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:104)
Caused: java.lang.Error
at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:110)
at hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:175)
at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
at jenkins.model.Jenkins$5.runTask(Jenkins.java:1131)
at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
2021-02-13 15:36:26.960+0000 [id=20] SEVERE hudson.util.BootFailure#publish: Failed to initialize Jenkins
java.lang.IllegalArgumentException: No hudson.slaves.Cloud implementation found for kubernetes
at io.jenkins.plugins.casc.impl.configurators.HeteroDescribableConfigurator.lambda$lookupDescriptor$11(HeteroDescribableConfigurator.java:211)
at io.vavr.control.Option.orElse(Option.java:321)
enter code here
I started getting this error after upgrading the jenkins chart version to 3.1.8 .
After upgrading to 3.1.9 the error has been fixed.
They seem to fix the configurations that were causing the error in the new version.
https://github.com/jenkinsci/helm-charts/compare/jenkins-3.1.8...jenkins-3.1.9
requirements.yaml
- name: "jenkins"
condition: jenkins.enabled
version: "3.1.9"
repository: "https://charts.jenkins.io"
First of all u need to change your chart repo, take this: https://github.com/jenkinsci/helm-charts
After try re-deploy your jenkins without pvc and plugins.
I got same issue and jenkins started after changed version on plugin:
https://github.com/jenkinsci/configuration-as-code-plugin/releases
I changed version from v1.46 to v1.47 and jenkins version from 2.263.4 to 2.279
For this use different tag from your jenkins/jenkins:lts to jenkins/jenkins it will take 2.279 or later
After this changes my jenkins get up

Unable to access file .vmtx (Jenkins plugin vSphere Cloud)

I am using Jenkins version 2.236 (but also tried with 2.263.1), vSphere Plugin version 2.24, vSphere Client version 6.7.0
When i start my job and go to jenkins logs i see that below:
enter image description here
This vmtx file is avaliable on vSphere client (i can download it, delete it, move by hands no problem), i also can Clone VM from template manualy, but plugin can't get access to it and clone it, it has an error
enter image description here
Please help, how to avoid this problem?
Unexpected exception encountered while provisioning agent dynamic3fofguaybl6yiwkjfe7jk5zm9
com.vmware.vim25.CannotAccessVmConfig
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at com.vmware.vim25.ws.XmlGenDom.fromXml(XmlGenDom.java:253)
at com.vmware.vim25.ws.XmlGenDom.fromXml(XmlGenDom.java:363)
at com.vmware.vim25.ws.XmlGenDom.fromXml(XmlGenDom.java:363)
at com.vmware.vim25.ws.XmlGenDom.fromXml(XmlGenDom.java:363)
at com.vmware.vim25.ws.XmlGenDom.fromXml(XmlGenDom.java:356)
at com.vmware.vim25.ws.XmlGenDom.fromXML(XmlGenDom.java:233)
at com.vmware.vim25.ws.XmlGenDom.fromXML(XmlGenDom.java:124)
at com.vmware.vim25.ws.SoapClient.unMarshall(SoapClient.java:253)
at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:96)
at com.vmware.vim25.ws.VimStub.retrieveProperties(VimStub.java:106)
at com.vmware.vim25.mo.PropertyCollector.retrieveProperties(PropertyCollector.java:98)
at com.vmware.vim25.mo.ManagedObject.retrieveObjectProperties(ManagedObject.java:146)
at com.vmware.vim25.mo.ManagedObject.getCurrentProperty(ManagedObject.java:167)
at com.vmware.vim25.mo.Task.getTaskInfo(Task.java:51)
Caused: org.jenkinsci.plugins.vsphere.tools.VSphereException: vSphere Error: Couldn't clone "ubuntu-18.04-dynamic-node-for-test". Clone task ended with status error.
Unable to access the virtual machine configuration: Unable to access file [esxi-datastore_nvme] ubuntu-18.04-dynamic-node-for-test/ubuntu-18.04-dynamic-node-for-test.vmtx
at org.jenkinsci.plugins.vsphere.tools.VSphere.newVSphereException(VSphere.java:1151)
at org.jenkinsci.plugins.vsphere.tools.VSphere.cloneOrDeployVm(VSphere.java:287)
at org.jenkinsci.plugins.vSphereCloudSlaveTemplate.provision(vSphereCloudSlaveTemplate.java:428)
at org.jenkinsci.plugins.vSphereCloudSlaveTemplate.provision(vSphereCloudSlaveTemplate.java:403)
at org.jenkinsci.plugins.vSphereCloud$VSpherePlannedNode.provisionNewNode(vSphereCloud.java:534)
at org.jenkinsci.plugins.vSphereCloud$VSpherePlannedNode.access$100(vSphereCloud.java:496)
at org.jenkinsci.plugins.vSphereCloud$VSpherePlannedNode$1.call(vSphereCloud.java:510)
at org.jenkinsci.plugins.vSphereCloud$VSpherePlannedNode$1.call(vSphereCloud.java:506)
at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
at jenkins.security.ImpersonatingExecutorService$2.call(ImpersonatingExecutorService.java:71)
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 java.lang.Thread.run(Thread.java:748)

Jenkins Pipepline is failing: Remote call on JNLP4-connect connection from XXX failed

My Jenkins pipeline is failing while checking out from svn. Below is the error.
Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to JNLP4-connect connection from nobuild01.sdi.pvt/152.144.34.14:50396
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741)
at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
at hudson.remoting.Channel.call(Channel.java:955)
at hudson.FilePath.act(FilePath.java:1036)
at hudson.FilePath.act(FilePath.java:1025)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:928)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:864)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:113)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:85)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:75)
at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47)
at hudson.security.ACL.impersonate(ACL.java:290)
at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
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 java.lang.Thread.run(Thread.java:748)
java.lang.NoClassDefFoundError: Could not initialize class jenkins.model.Jenkins
at hudson.scm.SubversionSCM.descriptor(SubversionSCM.java:2584)
at hudson.scm.SubversionSCM.createDefaultSVNOptions(SubversionSCM.java:1085)
at hudson.scm.SubversionSCM.createClientManager(SubversionSCM.java:1075)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1002)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:979)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2918)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:93)
at java.lang.Thread.run(Thread.java:745)
Caused: java.io.IOException: Remote call on JNLP4-connect connection from nobuild01.sdi.pvt/152.144.219.14:50396 failed
at hudson.remoting.Channel.call(Channel.java:961)
at hudson.FilePath.act(FilePath.java:1036)
Caused: java.io.IOException: remote file operation failed: c:\Dev at hudson.remoting.Channel#4b1b30ed:JNLP4-connect connection from nobuild01.sdi.pvt/152.144.34.14:50396
at hudson.FilePath.act(FilePath.java:1043)
at hudson.FilePath.act(FilePath.java:1025)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:928)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:864)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:113)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:85)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:75)
at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47)
at hudson.security.ACL.impersonate(ACL.java:290)
at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
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 java.lang.Thread.run(Thread.java:748)
Slave machine is running on openJDK, not Oracle java. so I used IcedTea to run .jnlp.
I checked my Jenkins service is running.
openjdkverion: java-1.8.0-openjdk-1.8.0.91-3
Also someone guild me where I can see the Jenkins log. I am running Jenkins master as a Docker container.
For Windows, go to Services (Start ā†’ Run: services.msc), find Jenkins and Jenkins Agent, right click ā†’ Restart.
If it does not help (UI is not responding) open the Windows Task Manager ā†’ Processes, kill the java.exe process, and restart the service once again.
ps -ef | grep jenkins
sudo kill -9 <pid>
This could be due to refSpec configuration on jenkins. In Source Code management, provide the SSH, github/any other git REPO URL .
Tap on Advanced Button and provide "refs/pull/:refs/remotes/origin/pr/" in RefSpec
In above configuration bold content might be creating problem, please remove and restart your jenkins.
In my case this solved problem for me.

Jenkins java.io.NotSerializableException when running slave on AWS ECS

A weird problem I came across: I run my slave as a docker image, sometimes as docker container on master node and other times on ECS(Fargate) using Amazon Elastic Container Service plugin.
I run this below piece of code
publishLambda(
awsAccessKeyId:"${env.AWS_ACCESS_KEY_ID}",
awsSecretKey:"${env.AWS_SECRET_ACCESS_KEY}",
awsRegion:"${lambda_config.region}",
functionARN:lambda_name,
functionAlias:"DEV"
)
It works fine when Iā€™m running the slave as docker container but when run on ECS, I get the following error after the lambda gets published successfully. I suspect its something with the hudson.remoting api when its trying to get a response across the network.
IMO hudson.remoting should be behaving the same irrespective of where the containers are running. How am i getting such discrepencies?
java.io.NotSerializableException:
com.xti.jenkins.plugin.awslambda.publish.LambdaPublishServiceResponse
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
at hudson.remoting.UserRequest._serialize(UserRequest.java:264)
at hudson.remoting.UserRequest.serialize(UserRequest.java:273) Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to
JNLP4-connect connection from
ec2-18-224-68-207.us-east-2.compute.amazonaws.com/18.224.68.207:40038
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741)
at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
at hudson.remoting.Channel.call(Channel.java:955)
at com.xti.jenkins.plugin.awslambda.publish.LambdaPublishBuildStep.perform(LambdaPublishBuildStep.java:58)
at com.xti.jenkins.plugin.awslambda.publish.LambdaPublishBuildStep.perform(LambdaPublishBuildStep.java:46)
at org.jenkinsci.plugins.workflow.steps.CoreStep$Execution.run(CoreStep.java:80)
at org.jenkinsci.plugins.workflow.steps.CoreStep$Execution.run(CoreStep.java:67)
at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
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)
Caused: java.io.IOException: Unable to serialize
com.xti.jenkins.plugin.awslambda.publish.LambdaPublishServiceResponse#4ec0e00f
at hudson.remoting.UserRequest.serialize(UserRequest.java:275)
at hudson.remoting.UserRequest.perform(UserRequest.java:223)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
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:93)
Caused: java.lang.RuntimeException
at com.xti.jenkins.plugin.awslambda.publish.LambdaPublishBuildStep.perform(LambdaPublishBuildStep.java:66)
at com.xti.jenkins.plugin.awslambda.publish.LambdaPublishBuildStep.perform(LambdaPublishBuildStep.java:46)
at org.jenkinsci.plugins.workflow.steps.CoreStep$Execution.run(CoreStep.java:80)
at org.jenkinsci.plugins.workflow.steps.CoreStep$Execution.run(CoreStep.java:67)
at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
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 java.lang.Thread.run(Thread.java:748) Finished: FAILURE
The reason for this was Class LambdaPublishServiceResponse in Amazon Elastic Container Service plugin was not inheriting java.io.Serializable.
And since java remoting over network from slave running on ECS(fargate) had to be serialized to be retrieved by master, this change had to be done. Have raised a PR https://github.com/XT-i/aws-lambda-jenkins-plugin/pull/100

Jenkins Artifactory Plugin not working with recent Artifactory version

We have the following steps in our Jenkinsfile (trying to upload artifacts to our Artifactory server):
def server = script.Artifactory.server("our-artifactory-server-id")
def uploadSpec = """{
"files": [
{
"pattern": "${sourcePath}",
"target": "${targetPath}"
}
]
}"""
server.upload(uploadSpec)
This used to work until we updated to a newer version of Artifactory. Ever since the update, we get the following error when running the build job:
java.io.IOException: Failed to deploy file. Status code: 400
at org.jfrog.build.extractor.clientConfiguration.client.ArtifactoryBuildInfoClient.uploadFile(ArtifactoryBuildInfoClient.java:656)
at org.jfrog.build.extractor.clientConfiguration.client.ArtifactoryBuildInfoClient.deployArtifact(ArtifactoryBuildInfoClient.java:343)
at org.jfrog.build.extractor.clientConfiguration.util.spec.SpecsHelper.deploy(SpecsHelper.java:291)
at org.jfrog.build.extractor.clientConfiguration.util.spec.SpecsHelper.uploadArtifactsBySpec(SpecsHelper.java:65)
at org.jfrog.hudson.generic.GenericArtifactsDeployer$FilesDeployerCallable.invoke(GenericArtifactsDeployer.java:189)
at org.jfrog.hudson.generic.GenericArtifactsDeployer$FilesDeployerCallable.invoke(GenericArtifactsDeployer.java:130)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2750)
at hudson.remoting.UserRequest.perform(UserRequest.java:181)
at hudson.remoting.UserRequest.perform(UserRequest.java:52)
at hudson.remoting.Request$2.run(Request.java:336)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at ......remote call to docker-bc26fb0b91c4(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1554)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:281)
at hudson.remoting.Channel.call(Channel.java:839)
at hudson.FilePath.act(FilePath.java:987)
Caused: java.io.IOException: remote file operation failed: /home/jenkins/workspace/tration_feature_jenkinsfile-ANARWI2SDBPRVZNIYHCS6XKXIAD2SZ5ZTHM6DRXHYSARAQHPWEMQ at hudson.remoting.Channel#4c39a5aa:docker-bc26fb0b91c4
at hudson.FilePath.act(FilePath.java:994)
at hudson.FilePath.act(FilePath.java:976)
at org.jfrog.hudson.pipeline.executors.GenericUploadExecutor.execution(GenericUploadExecutor.java:52)
at org.jfrog.hudson.pipeline.steps.UploadStep$Execution.run(UploadStep.java:65)
at org.jfrog.hudson.pipeline.steps.UploadStep$Execution.run(UploadStep.java:46)
at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47)
at hudson.security.ACL.impersonate(ACL.java:260)
at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
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 java.lang.Thread.run(Thread.java:748)
Finished: FAILURE
Some background regarding our setup:
Jenkins version 2.69
Artifactory version 5.8.4
Artifactory plugin version 2.14.0
the error started to appear with a recent update of Artifactory
the Artifactory log shows no output for the error
we are sitting behind a proxy, but no_proxy is set correctly, at least we can curl https://... to our Artifactory host
we have self-signed certificates for Artifactory, but they should be properly added to the java truststore and the system truststore, since we can open URLs in java apps as well as with curl without any issues.
Any idea how we could debug this issue?
I had a very similar issue and found the solution in the configuration of the Artifactory-Jenkins plugin (manage jenkins --> configure system --> artifactory).
What I did was changing the Artifactory server URL from:
https://<artifactorydomain.com>
to the new URL (adding the /artifactory):
https://<artifactorydomain.com>/artifactory
Hope this helps.

Resources