With the command gradle tasks one can get a report of all available tasks. Is there any way to add a parameter to this command and filter tasks by their task group.
I would like to issue a command like gradle tasks group:Demo to filter all tasks and retrieve a list of only those tasks that belong to the task group called Demo.
From v5.1, you can do this: gradle tasks --group=<group-name>
Gradle docs.
You can do so by adding the following task to your build script:
task showOnlyMyTasks << {
tasks.each {
task -> if (task.group == 'My task group name') {
println(task.name)
}
}
}
And then run:gradle showOnlyMyTasks
If you need only the list, you can use gradle -q
Old answer: There is no such feature. Feel free to suggest new features at http://forums.gradle.org.
Now available since Gradle 5.1, see this answer: https://stackoverflow.com/a/54341658/4433326
Related
Getsolution.exe will give New data available or no new data available, if new data available then next jobs should be executed else nothing should be executed. How should i do it? (i am working on classic editor)
example: i have set of tasks, consider 4 tasks:
task-1: builds the solution
task-2: runs the Getstatus.exe which get the status of data available or no data available
task-3: i should be able to use the above task and make a condition/use some api query and to proceed to publish an artifact if data is available if not cleanly break out of the task and stop the build. it Shouldn't proceed to publish artifact or move to the next available task
task-4:publish artifact
First what you need is to set a variable in your task where you run Getstatus.exe:
and then set condition in next tasks:
If you set doThing to different valu than Yes you will get this:
How to refer previous task and stop the build in azure devops if there is no new data to publish an artifact
Since we need to execute different task based on the different results of Getstatus.exe running, we need set the condition based on the result of Getstatus.exe running.
To resolve this, just like the Krzysztof Madej said, we could set variable(s) based on the return value of Getstatus.exe in the inline powershell task:
$dataAvailable= $(The value of the `Getstatus.exe`）
if ($dataAvailable -eq "True")
{
Write-Host ("##vso[task.setvariable variable=Status]Yes")
}
elseif ($dataAvailable -eq "False")
{
Write-Host ("##vso[task.setvariable variable=Status]No")
}
Then set the different condition for next task:
You could check the document Specify conditions for some more details.
I'm using the gradle tooling API to run functional tests for my own build script.
I would like to access tasks' properties, e.g. the destinationDir of a JavaCompile task, and i don't know how to accomplish this.
Simple example:
Snippet in my buildScript (I defined a SourceSet 'openjpa'):
compileOpenjpaJava {
destinationDir = file(getOpenjpaClassesDir())
}
private String getOpenjpaClassesDir(){
return "build/classes_openjpa"
}
In my functional test I read about a way to access the tasks, but I cannot access the destinationDir-property.
GradleProject project = connection.getModel(GradleProject.class);
project.tasks.each { myTask ->
if ("compileOpenjpaJava" == myTask.name) {
return myTask.destinationDir.absolutePath // brings a runtime error like: unknown property 'destinationDir'
}
}
A similar question w/o answers is here: Gradle tooling api get task outputs
Is it possible at all to access tasks' properties?
Thanks
Jan
Currently I have in my gradle.build file the tasks:
task helloA {
println 'hello A!'
}
task helloB {
println 'hello B!'
}
However executing task helloA via Gradle Tasks/other/helloA prints on the console:
hello A!
hello B!
:helloA UP-TO-DATE
BUILD SUCCESSFUL
However I would expect it to just print: 'hello A!' instead of
hello A!
hello B!
together.
How do I change that? I read through the gradle docs, but coudln't find something about that apart from some extensive workaround.
No task is executed at all in your buildfile, they are just configured.
Be aware that there are three phases in a Gradle run. Initialization, configuration and execution. In initialization phase, you define which projects are part of the build and where they are on disc (basically settings.gradle execution). In configuration phase all tasks are configured. In execution phase the tasks that need to be executed (explicitly called tasks or default tasks, depended upon directly or transitively by explicitly called or default tasks).
Try this and you will see:
task helloA {
println 'configure A!'
doLast {
println 'execute A!'
}
}
task helloB {
println 'configure B!'
doLast {
println 'execute B!'
}
}
I have following code in my plugin:
#Override
void apply(Project project) {
project.extensions.create(EXTENSION,TestExtension)
project.task("task1") << {
println "Task 1"
println(project.mmm.test)
def extension = project.extensions.findByName(EXTENSION)
println(extension.test)
}
project.task("task2",type: TestTask) {
println "Task 2 "
def extension = project.extensions.findByName(EXTENSION)
// conventionMapping.test = {extension.test}
// println(project.extensions.findByName(EXTENSION).test)
// test = "test"
}
}
In task 1 extension.test return correct value. However in task2 extension.test always return null. What I am doing wrong? Is there a better way to pass some of the extensions values as input for task? I am using gradle 1.12 with jdk 1.8 on Mac. Best Regards
Edit :correct version:
project.task("task2", type: TestTask) {
project.afterEvaluate {
def extension = project.extensions.findByName(EXTENSION)
println(project.extensions.findByName(EXTENSION).test)
test = project.extensions.findByName(EXTENSION).test
}
}
task1 prints the value at execution time (notice the <<), task2 at configuration time (before the rest of the build script after the apply plugin: ... has been evaluated). This explains why the println for task1 works as expected, and the println for task2 doesn't.
However, configuring a task at execution time is too late. Instead, a plugin needs to defer reading user-provided values until the end of the configuration phase (after build scripts have been evaluated, but before any task has been executed). There are several techniques for doing so. One of the simpler ones is to wrap any such read access with project.afterEvaluate { ... }.
Updated answer as some time has passed and Gradle evolved its concepts and its syntax in the meantime.
To use up-to-date and optimally configured task you should use following syntax:
tasks.register("task1") {
doLast {
def extension = project.extensions.findByName(EXTENSION)
println(project.extensions.findByName(EXTENSION).test)
test = project.extensions.findByName(EXTENSION).test
}
}
Task Action:
A task has both configuration and actions. When using the doLast, you
are simply using a shortcut to define an action. Code defined in the
configuration section of your task will get executed during the
configuration phase of the build regardless of what task was targeted.
Deprecated << Operator
<< was deprecated in 4.x and removed in 5.0. See task action (doLast) on how to evaluate task logic at execution phase when all extensions and configurations should be evaluated.
Task Configuration Avoidance
To avoid the cost of creating a task if this won't be executed on your invoked Gradle command TaskContainer.register(String) method.
Avoid afterEvaluate
afterEvaluate should in most cases be avoided, see #sterling's comments from the link. You have now the possibility to evaluate task action part in execution phase, and additionally you can also rely on Task Inputs/Outputs with the combination of Lazy Configuration.
Consider the following Rake tasks:
task deploy => [:package] do
end
task package => [:build] do
end
task build do
end
Is there a way to invoke Rake on the command line to execute the package and deploy tasks, but not the build task?
Short answer, no.
The way I usually go about this is instead of using the dependant task notion like you have above:
task deploy => [:package] do
end
I create an alias task for whatever action that is to be completed:
task all => [:build, :package, :deploy]
task fastDeploy => [:package, :deploy]
task deploy do
end
task package do
end
task build do
end
It's not very elegant, but I do find it to be more readable and you can visibly see the dependency of tasks on other tasks instead of the kind of spaghetti code structure the dependant notion can result in... when you have a lot of task it can be awkward to debug the logic to figure what's gone wrong and where at times.
Hope this helps.