we recently updated Jenkins and when running one of our jobs to upload a wildcard cert to aks it no longer excepts ReadToString(). It offers a possible solution but simply changing it doesn't resolve the issue.
Version: Jenkins 2.361.1
Pipeline Error:
hudson.remoting.ProxyException: groovy.lang.MissingMethodException: No signature of method: java.lang.String.readToString() is applicable for argument types: () values: []
Possible solutions: toString(), toString(), toString()
Part of the the config:
def fb64crt = input message: 'Upload Cert (*.crt) File. There is no validation on this input so be sure what you select!',
parameters: [base64File('crtfile')]
writeFile(file: 'tls.crt', text: fb64crt.readToString())
I thought if I change it to writeFile(file: 'tls.crt', text: fb64crt.toString()) that it would accept the contents of the function but that doesn't seem to work. Any suggestions are greatly appreciated. I'm not at all familiar with groovy.
Thanks.
Related
I have a DSL script that creates a new job. Part of the code looks like this:
pipelineTriggers {
triggers {
// cron('''${SCHEDULE}''')
parameterizedTimerTrigger {
parameterizedCron('''${SCHEDULE} % INSTANCE=testserver''')
}
}
}
When I run it, I got the error:
Processing provided DSL script
ERROR: (script, line 6) No signature of method: javaposse.jobdsl.dsl.jobs.WorkflowJob.pipelineTriggers() is applicable for argument types: (script$_run_closure1$_closure3) values: [script$_run_closure1$_closure3#8160ead]
Finished: FAILURE
Line 6 is the pipelineTriggers {. I can not find any info online for the particular error. The Job DSL plugin is v. 1.81.
When I tried to use cron('''${SCHEDULE}'''), I got the same error.
If I take off the pipelineTriggers { and just use the triggers, I got an warning saying triggers is deprecated.
Any idea how I can fix this issue?
Thanks!
I want to load a groovy file in a DSL file. If I process the DSL file I got following error message:
Processing DSL script folderA/job.dsl
ERROR: (job.dsl, line 2) No signature of method: job.load() is applicable for argument types: (org.codehaus.groovy.runtime.GStringImpl) values: [./build.groovy ]
Possible solutions: find(), job(java.lang.String), find(groovy.lang.Closure), wait(), run(), run()
The first two lines of my file job.dsl:
def workspace = '.'
def module = load "${workspace}/build.groovy "
I understand the error message in this way, there is no method load() in object job. The question is, how can I access global/build-in methods like load() in a DSL file?
According to the message there is no load() method with a signature that contains a groovy.lang.GString parameter.
You could use:
a Double-quoted string: workspace + "/build.groovy" or
a Single-quoted string: workspace + '/build.groovy'
without interpolation which are interpreted as java.lang.String.
See also Load script from groovy script.
I'm running
Jenkins 2.235.1
promoted-builds 3.5
JobDSL 1.77
When I do the small example as the documentation says.
properties {
promotions {
promotion {
name('build')
icon('star-silver')
condition {
selfPromotion('false')
}
}
}
}
I get the following error:
Caused by: javaposse.jobdsl.dsl.DslScriptException: (script, line 86) No signature of method: javaposse.jobdsl.dsl.helpers.properties.PropertiesContext.promotions() is applicable for argument types: (webshop_v8.script$_run_closure1$_closure7$_closure20) values: [webshop_v8.script$_run_closure1$_closure7$_closure20#265f0971]
According to the documentation, I have added it correctly, but my jobDslTest doesn't allow it. Someone that can give me a hint? I'm sort of lost atm.
The problem was in my case:
We are using the Job DSL Plugin(1) that provides tests for us, to execute them locally before pushing the commit.
This plugin was still using an old version of Jenkins, by adding a newer version to my build.gradle my problem was solved.
dependencies {
.
.
.
jobDslTestRuntime "org.jenkins-ci.main:jenkins-war:2.235.1"
}
https://github.com/AOEpeople/gradle-jenkins-job-dsl-plugin
I have a shared pipeline library code. The library is loaded implicitly in my Jenkins and I'm calling one of the methods using the following code in my Jenkinsfile:
node {
CheckOut {}
}
I've also tried using CheckOut.call() & CheckOut.call([:],{}) but to no avail.
Keep getting the following error:
hudson.remoting.ProxyException: groovy.lang.MissingMethodException: No signature of method: CheckOut.call() is applicable for argument types: (org.jenkinsci.plugins.workflow.cps.CpsClosure2) values: [org.jenkinsci.plugins.workflow.cps.CpsClosure2#668faf1f]
Possible solutions: call(), wait(), any(), wait(long), main([Ljava.lang.String;), any(groovy.lang.Closure)
P.S. - The error is not specific to one function and is happening for all the other functions of the library as well.
Found the issue. While configuring the shared library repo in Jenkins Global Configuration, fill in the link without .git in the end.
For example, use https://github.com/arghyadeep-k/jenkins-shared-library and not https://github.com/arghyadeep-k/jenkins-shared-library.git.
And, then invoke the functions in your Jenkinsfile as
node{
checkOut.call()
}
Running the application with grails run-app works fine but after deploying in Tomcat 7 I get following error.
groovy.lang.MissingMethodException:
No signature of method: static com.digithurst.hdspro.web.Responder.respond()
is applicable for argument types: (ResourceListCmd, QueryCmd, groovy.util.ConfigObject)
values: [ResourceListCmd#5c380e, ...]
Possible solutions: respond(HttpResource, java.lang.Object, java.lang.String)
As already said, this works outside of Tomcat. The way the method is called is exactly as it is implemented. The ResourceListCmd implements the interface HttpResource which makes it a perfect fit. This error also occurs if the first parameter is null.
groovy.lang.MissingMethodException:
No signature of method: static com.digithurst.hdspro.web.Responder.respond()
is applicable for argument types: (null, QueryCmd, groovy.util.ConfigObject)
values: [null, ...]
Possible solutions: respond(HttpResource, java.lang.Object, java.lang.String)
More on the environment:
Windows 7 64 Bit
Java 7 U45 x86
Grails 2.3.4
Tomcat 7.0.47
I have already cleaned the .grails and .m2 folders in the user directory and performed a grails clean berfore creating the war file.
[Edit after answer of H3rnst]
Controller:
def index() {
try {
ResourceListCmd configs = configService.search()
respond Responder.respond(configs, new QueryCmd(level: 'list'),
grailsApplication.config.grails.serverURL)
}
catch (Exception e) {
render status: INTERNAL_SERVER_ERROR
}
}
ResourceListCmd:
interface HttpResource {
...
}
abstract class AbstractHttpResource implements HttpResource {
...
}
class ResourceListCmd extends AbstractHttpResource {
...
}
Responder:
class Responder {
static def respond(HttpResource resource, def query, String serverURL) {
...
}
}
Your war (or tomcat server classpath) contain a duplicate or wrong version of jar that contains the class com.digithurst.hdspro.web.Responder. (The version of the class you are using developing an launching with run-app is different from the one tomcat load running your war)
You could try to unpack the war end verify the version of the problematic jar and/or use a tool like jarscan to scan for duplicate classes.
You could even try to use the command dependecy-report and search for duplicate injection of the same lib. Probably two different plugins your are using are incorporating to differente versions of the same lib causing the problem.
marko's suggestion doing run-war actually gave the final clue to solving this thing. It wasn't a problem with Tomcat but rather the environment the app was running in. run-app as well as run-war both use the "development" environment by default and therefore it worked. Only in "production" it did not, which is what is used when deployed to Tomcat.
The actual culprit was part of the configuration and the error message was right, although unexpected. I'm calling the Responder.respond() method with grailsApplication.config.grails.serverURL. The serverURL was only set in "development" mode but not in "production". That's why Groovy/Java complained about the method signature:
(ResourceListCmd, QueryCmd, groovy.util.ConfigObject) vs (HttpResource, java.lang.Object, java.lang.String)
The clue is the last parameter, the first two are correct. However, I would've expected null as the value instead of a completely different type.