I have the following task in my build.gradle file:
task myTask(type:Exec) {
def stdout = new ByteArrayOutputStream()
exec {
commandLine 'cmd', '/c', 'whoami'
standardOutput = stdout;
}
println "Output: $stdout"
}
When I run my task with ./gradlew myTask, I get the following output:
> Configure project :
Output: retrovius
> Task :myTask FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':myTask'.
> execCommand == null!
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 2s
1 actionable task: 1 executed
The task successfully outputs my username (retrovius), then fails anyway. Any pointers for what I'm doing wrong?
Depending on what you want to achieve, the answer you found is probably still not correct.
All tasks have two main stages: configuration and execution. Everything you put in the outermost block to the task definition is part of the configuration. And the exec method actually executes the command whenever that block of code is evaluated. So when you type:
task myTask() {
def stdout = new ByteArrayOutputStream()
exec {
commandLine 'cmd', '/c', 'whoami'
standardOutput = stdout;
}
println "Output: $stdout"
}
Then it means you are running the whoami command no matter what task you specify. If you run gradle -i help, it will print the name. I expect this is not what you intend.
Most of the time, you will want to run a command only when the task is actually executed. So if you want the command to only run if you type gradle -i myTask, you will need to do defer it to the execution stage instead. There are two ways you can do that.
Either you can put everything in a doLast block like this:
task myTask() {
doLast {
def stdout = new ByteArrayOutputStream()
exec {
commandLine 'cmd', '/c', 'whoami'
standardOutput = stdout
}
println "Output: $stdout"
}
}
Or you use the Exec type, like you already tried. The reason it didn't work for you is that you need to configure it with the command you like - and not actually run the command through the exec method. It could look like this:
task myTask(type: Exec) {
commandLine 'cmd', '/c', 'whoami'
standardOutput = new ByteArrayOutputStream()
doLast {
println "Output: $standardOutput"
}
}
You an also probably get rid of the cmd /c part. And println should only be used for debugging - use logger.info (or .warn, etc) if you need to output something to the user.
I figured out that the only thing I was doing wrong was to include the (type:Exec) in the definition of my task. If I place the following code in my build.gradle file:
task myTask() {
def stdout = new ByteArrayOutputStream()
exec {
commandLine 'cmd', '/c', 'whoami'
standardOutput = stdout;
}
println "Output: $stdout"
}
I get the following output:
> Configure project :
Output: retrovius
BUILD SUCCESSFUL in 2s
My mistake must have been that I was defining the task to be of type exec, but not giving it a command to run. This reveals a fundamental misunderstanding of the exec task and task type on my part. If anyone knows more specifically what I did wrong, please feel free to comment and explain or post a better answer.
Related
In $HOME/.gradle/init.gradle I have:
gradle.buildFinished { buildResult ->
commandLine 'bash', "blah blah blah"
}
Doing gradle build the build succeeds, but after it succeeds I get the error:
Could not find method commandLine() for arguments [bash, blah blah blah] on build 'FooBar' of type org.gradle.invocation.DefaultGradle.
The answer to the question Could not find method commandLine() doesn't help as either putting (type: Exec) after gradle.buildFinished or wrapping the whole thing in exec { } causes Gradle to fail right from the start rather than the build succeeding and then my post-build hook failing.
I'm using Gradle version 6.3
You've misconfigured commandLine. With the following build.gradle:
task lol {
doLast {
println "lol"
}
}
and ~/.gradle/init.gradle:
gradle.buildFinished { buildResult ->
exec {
commandLine 'bash', '-c', 'echo lol2'
}
}
it works as expected.
I have a Jenkins scripted pipeline set up where I execute a number of Maven builds. I want to treat one of them as non-fatal if the root cause is a known one.
I have tried to achieve that by inspecting the Exception's message, e.g.
try {
sh "mvn -U clean verify sonar:sonar ${sonarcloudParams}"
} catch ( Exception e ) {
if ( e.getMessage().contains("not authorized to run analysis")) {
echo "Marking build unstable due to missing SonarCloud onboarding. See https://cwiki.apache.org/confluence/display/SLING/SonarCloud+analysis for steps to fix."
currentBuild.result = 'UNSTABLE'
}
}
The problem is that the exception's message is not the one from Maven, but instead "script returned exit code 1".
There is no further information in e.getCause().
How can I access the cause of the Maven build failure inside my scripted pipeline?
You can get the command output, then parse it containers specific message.
def output = sh(
script: "mvn -U clean verify sonar:sonar ${sonarcloudParams}",
returnStdout: true
).trim()
echo "mvn cmd output: ${output}"
if(output.contains('not authorized to run analysis')) {
currentBuild.result = 'UNSTABLE'
}
// parse jenkins job build log
def logUrl = env.BUILD_URL + 'consoleText'
def cmd = "curl -u \${JENKINS_AUTH} -k ${logUrl} | tail -n 50"
def output = sh(returnStdout: true, script: cmd).trim()
echo "job build log: ${output}"
if(output.contains('not authorized to run analysis')) {
currentBuild.result = 'UNSTABLE'
}
One option is to inspect the last log lines using
def sonarCloudNotEnabled = currentBuild.rawBuild.getLog(50).find {
line -> line.contains("not authorized to run analysis")
}
However, this does not work by default. On the Jenkins instance I'm using it errors out with
Scripts not permitted to use method org.jenkinsci.plugins.workflow.support.steps.build.RunWrapper getRawBuild. Administrators can decide whether to approve or reject this signature.
I am making task which runs bash script
task wsUpload(type: Exec) {
commandLine '../scripts/ws_upload.sh ' + rootProject.ext.VERSION_CODE
}
however it returns
Caused by: java.io.IOException: Cannot run program "../scripts/ws_upload.sh 30" .... No such file or directory
if i ran same command without arguments
task wsUpload(type: Exec) {
commandLine '../scripts/ws_upload.sh'
}
then command is executed. What am i doing wrong?
Add args like this
task wsUpload(type: Exec) {
commandLine '../scripts/ws_upload.sh'
args = ["args"]
}
How can I get a gradle project.exec or Exec task to not display all information about the commandline?
code
project.exec {
workingDir = exeDir.absolutePath
executable = starter.absolutePath
args = commandLine.split().toList()
environment << envVars
project.logging.captureStandardOutput LogLevel.INFO
standardOutput = outputStream
errorOutput = outputStream
}
output
Starting process 'command 'regexIdentifier''. Working directory:
/home/code/ Command: /home/code/bin/regexIdentifier server username
password ...
Successfully started process 'command '/home/code/bin/regexIdentifier''
I need to execute a cmd with a password via gradle Exec task and want gradle to not display commandline upon execution
You can keep the gradle Exec task from printing output by default by overriding the standardOutput and errorOutput streams
standardOutput = new ByteArrayOutputStream()
errorOutput = new ByteArrayOutputStream()
However, this doesn't prevent the command from showing up when you run with the --info flag.
I starting playing around gradle and trying to understand the purpose of <<.
On executing gradle -q task0 when build.gradle contains gave me task 0
4.times { counter ->
task "task$counter" <<{
println "task $counter"
}
}
where as executing gradle -q test{0123} when build.gradle contains
4.times { counter ->
task "task$counter" {
println "task $counter"
}
}
returning
task 0
task 1
task 2
task 3
Can someone help in understanding purpose of <<?
If you have << it will execute the print lines when the task is executed and not having it executes the print lines when the task is configured.
This can effect your output since the Gradle Lifecycle is Initialization > Configuration > Execution.
For example if your build.gradle contains:
task "task0" << {
println "task 0"
}
task "task1" {
println "task 1"
}
Then if you execute task0 you will get:
> gradlew -q task0
task 1
task 0
Even though you would only expect task 0 to print. While if you execute task1 you get:
> gradlew -q task1
task 1
This is because task1 is printing out during configuration which even though you are not running it, the whole build.gradle file gets read in during the configuration phase to determine what gets executed. You could even go:
> gradlew clean
task 1
And you get your output from task1.
I think the problem here is what << means. It is predefined shift left operator and with it we say to a Gradle task. "Gradle task, I want closure which is after << to be put as your last action".So with
task "taskHello" <<{
println "Hello Gradle action"
}
you say in my build I have a task, which name is taskHello and I want when excecute it with
gradle taskHello
To do action
{
println "Hello Gradle action"
}
<< is a syntax sugar short for doLast{}, so you can rewrite your task like this:
4.times { counter ->
task "task$counter" {
doLast{
println "task $counter"
}
}
}