I want to use the Gradle Tooling API to invoke Gradle from an Eclipse plugin through the Buildship plug-ins. I am able to run basic tasks without problems.
One of my use cases is to execute the gradle init task in a new project folder, but to work non-interactively I have to pass the --type command line argument (or set the type property) on the init task. I can't find any way in the tooling API to set the properties of a task or to pass a task-specific command line argument.
I have tried BuildLauncher.addArgument("--type", "plain") but this is interpreted as an argument to Gradle itself, which is invalid.
How can I pass the --type plain argument to the init task?
After reading the docs here, I discovered you can set the task arguments via the Gradle command line build arguments. The important bit in the docs is:
Also, the task names configured by BuildLauncher.forTasks(String...) can be overridden if you happen to specify other tasks via the build arguments.
In my case I wanted to run gradle tasks --all via the tooling api. To get this working, I don't specify the task to run via forTasks(), I simply do not call that method. I set the task to run as part of the arguments via withArguments(). (In this case the arguments will be tasks --all).
I assume this should work the same for the init task.
Related
I am trying to setup a Jenkins pipeline to trigger builds using gradle for multiple environments.My requirement is that the artifacts produced when I run gradlew clean build should produce artifacts with name indicating the environment for which the pipeline was run. Example my-application-dev.jar
The value of the environment would be selected by the user when build will be triggered.
What is the optimal way to achieve this ? Does build allow to configure any such property via command line or do I need to define a task in my build.gradle and define properties within that task for which I will pass value from command line
There are basically two ways.
The first one is to pass these naming-relevant pieces of information to the gradlew process, e.g. via -D or -P properties.
Then you need the Gradle build to be aware of these parameters and craft the artifact names it produces accordingly.
The second one is arguably better and more contained. You simply rename the artifacts produced by the gradlew command after it completes, in the Jenkinsfile. This works well if the pipeline decides what to do with these artifacts (e.g. publish to a repository) as opposed to the gradle script doing it (in which case you would most likely be better off using the first method).
I am using gradle tooling api and I encountered the following scenario.
There is a project that applies a certain plugin P which creates a task T only if the property shouldApplyP is passed.
Hence, if you will run ./gradlew tasks --all you won't see task T, but if you will run
./gradlew -PshouldApplyP tasks --all you will see task T.
In gradle tooling api, once a ProjectConnection has created I can do
connection.getModel(GradleProject.class).getTasks()
But I can't see this specific task. Is there a way to pass the project connection this property
-PshouldApplyP so it will be presented in the getTasks() method?
connection.newBuild()
.withArguments("-PshouldApplyP", "tasks --all")
.run()
I am new to bigtop architecture, I would like to know
how does bigtop know the real build command to launch for this specific package after ./gradlew {package}-rpm, I assume there must be some kind of configs define the real build command. (The package is a maven based project)
Thank you.
I'm not familiar with Bigtop, but I am familiar with Gradle. See here for the Gradle task definition that you're referring to: https://github.com/apache/bigtop/blob/2d6f3dd7b7241aa2191c9ebc5a502a1415932464/packages.gradle#L460
The command that the task will execute is given under the exec directive: rpmbuild <command>. command is an array of arguments defined just above that directive. Most of its arguments are derived from the config object, which is basically a nested map (like a JSON object) produced by Groovy's ConfigSlurper, which reads the input BOM file as if it were a Groovy file.
So:
"Slurp" the BOM configuation into the config object
For each "component" defined within the config configuration, produce a set of tasks (${package}-rpm and others)
When configuring the ${package}-rpm task, use the BOM configuration to derive the command arguments using the logic provided within the task closure
Upon execution, run rpmbuild with the aforementioned command arguments
Is there a way to pass command line arguments to a program executed via Gradle run task in IntelliJ IDEA?
In the terminal, I can simply do this:
./gradlew run --args="-hello", which will pass the command line argument '-hello' to the program as expected.
However, if I add --args="-hello" to the IDEA Run Configuration (as in the image below), all I get is an error, which reads "failed", with this output:
10:08:50: Executing task 'run --args="-hello"'...
10:08:50: Task execution finished 'run --args="-hello"'.
A similar question, but no good answer: How do I use Gradle bootRun with --args in Intellij
Apparently this is a known issue in IntelliJ IDEA: Cannot use Gradle 4.9 --args option in "Arguments" field of a Gradle run configuration
The solution that worked best for me was to insert the run command in the Arguments section:
If I place the line run --args="-username=john -password=wayne" in the Tasks field (as also suggested in the link), it will complain about unmatched quotes due to the space between the two arguments.
Arguments can be passed by adding --args="" to the run section.
I have a current setup in my build.gradle that I'm trying to understand. I need a number of tasks to go off in a very specific order and execute all with one task call. The setup I want looks like this:
1.) Run liquibase changeset into predefined database
2.) Run a number of tests against database
3.) Rollback all changes made with the previous changeset
I want the database in a 'clean' state every time I test it. It should have only the changes I expect and nothing else. The liquibase is set up with the Gradle plugin for it and the changeset is applied/updated. However, I don't want to call the command manually. This will be something that needs to run in continuous integration, so I need to script it so I simply have our CI call one task and it then runs each task, in order, until the end. I'm unsure of how to call the Gradle command-line task from inside of itself (ie inside the build.gradle file) and then also pass parameters to it (since I'll need to call some type of rollback command task to get the database to be what it was before calling the update).
Right now, all I'm doing is calling the command line tasks like this:
$ gradle update
$ gradle test
$ gradle rollbackToDate -PliquibaseCommandValue=2016-05-25
Again, I can't call them by the command line alone. I need a custom task inside Gradle so that I could just call something like:
$ gradle runDatabaseTests
...And I would have it do everything I expect.
There is no gradle way to invoke/call a task from another task directly. What you can do instead is to use dependsOn or finalizedBy to setup task dependencies which will force the prereq tasks to run first.
If you declare a task:
task runDatabaseTests(dependsOn: [update, test, rollbackToDate]) << {
println "I depend on update, test and rollbackToDate"
}
when you call
gradle runDatabaseTests -PliquibaseCommandValue=2016-05-25
it will force update, test and rollbackToDate first. You can control the order in which they're run, if you care about that, by using mustRunAfter and/or shouldRunAfter