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
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 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.
We are migrating our project from Maven to Gradle. Our CI uses system properties like -Dwebdriver.type=firefox to set certain behaviour thus we don't want to hardcode such props in gradle.properties file etc. Is there a way to provide a system property with a dot in the name using command line?
If you run the following:
build.gradle:
logger.lifecycle("some.property ${System.properties['some.property']}")
with:
gradle -Dsome.property=lol
It should give you the expected output.
Along the lines of this answer (which works for me, BTW) and the javadocs, I tried
gradle.startParameter.consoleOutput = org.gradle.api.logging.configuration.ConsoleOutput.Rich
in my ~/.gradle/init.gradle. However, I still need --console=rich to get color output. Why?
Tested with Gradle 2.14.1 and 3.2.1.
Terminal is cygwin urxvt with TERM variable set to rxvt-unicode-256color.
Since Gradle 4.3 you can use org.gradle.console property in gradle.properties:
org.gradle.console=rich
A new console verbose mode will print outcomes of all tasks (like UP-TO-DATE) like Gradle 3.5 and earlier did. You can set this via --console=verbose or by a new Gradle property org.gradle.console=(plain rich verbose).
I am not sure if you can force the rich console from a gradle script, as the detection happens likely before the script is interpreted.
NativeServices class provides the integration with the console. If you look at the source code, there are two messages possibly printed in log:
Native-platform terminal integration is not available. Continuing with fallback.
Unable to load from native-platform backed ConsoleDetector. Continuing with fallback.
The latter might give you more information why. Try running the gradle script with --debug. You will likely find out that you are missing a native library that is either not available in cygwin or it is, but is not on library path.
I believe it works when you specify the rich console from the command line, because gradle forces the colours even though the console doesn't indicate it supports them.
Does it work if you don't use the cygwin console in Windows native command line or maybe GitBash?
There is a workaround how you can make this work. You can create an alias in cygwin that will always add the --console=rich.
If you are using gradle wrapper, you can edit the gradlew script and add the command line parameter. To make it automated, you can change the wrapper task to alter your script in the doLast part.
Create a file called gradle.properties inside your ~/.gradle/ folder.
Inside gradle.properties, add the line org.gradle.console=rich.
Each builds will run under --console=rich automatically because the new gradle.properties will be merged with the gradle.properties of your project.
If your project's gradle.properties contains the same tag as the local file, your project's will be used overriding the local file's
If you are on Linux/Mac set
alias gradle='gradle --console rich'
in your ~/.bashrc.
In Gradle Wrapper, add the following line:
org.gradle.console=rich
to ./gradle.properties in the root folder, where the gradlew script is located.
I have a go lang application which exposes a rest API and logs the information to DB. I am trying to convert the make file to gradle build. Is there any default way similar to maven2gradle plugin or the gradle build file should be written manually? I checked the syntactical differences between gradle and make file but still not clear about passing run time arguments to gradle that is similar to
run:build
./hello -conf=/apps/content/properties/prop.json -v=0 -logDest="FILE" -log_dir="/var/log/logdir"
hello is my executable and others are the runtime arguments. This is my first attempt in migrating make to gradle and I couldnt find any clear documentation. Please help.
As far as I have checked, there is no direct plugin that could do this task. As a workaround, the build execution could be written as seperate tasks in gradle and ordered accordingly. Tasks here would contain setting Go path, installing dependencies and building the application and would be run as command line process in Gradle. Gradle provides support to run command line processes as described in gradle documentation. Hope it helps.