Starting from version 2.9 of the SonarQube scanner it is possible to reference variables from within sonar-project.properties:
https://www.sonarsource.com/resources/product-news/2017/03/2017-03-15-sonarqube-scanner-2.9-released.html
To me, the obvious use case of this feature is to avoid having to declare the version of the project twice (once in code and once in sonar-project.properties).
For example, in Swift projects the version is defined in a .plist file as an XML value. Is there an obvious simple method to retrieve this value and reference it in the sonar-project.properties file?
Update: I have managed to get this to work in a TeamCity build (command line build step):
echo "##teamcity[setParameter name='env.APP_VERSION' value='$(/usr/libexec/PlistBuddy -c "Print :CFBundleShortVersionString" "MyApp/Info.plist")']"
and then referencing the variable in sonar-project.properties:
sonar.projectVersion=${env.APP_VERSION}
No 'obvious simple method' that I can think of. One approach could be to have a small script picking the version from the .plist and setting it as an environment variable. Environment variable which can then be referenced from sonar-project.properties.
Related
Passing the version to POM.xml.
It shows warning. 'version' contains an expression but should be a constant.
I have to remove this.
I have one Ant project and another maven project. I made one runconfiguration for Ant project where I made one variable with some value suppose 13.2.1
by opting external tool configuration that variable come in list now.now able to pass that variable like -Dversion="${versionjar}".
its working perfactly.
since this versionjar is already set in eclipse. I want to use this while I want to run the maven project by runconfiguration.
want to pass in create manage and runconfiguration like in goal section install -Dversion="${versionjar}" but its not working .
I have to set this variable here also by add button.
How can I pass the variable from eclipse command line like :install -version="${version}"? version is vailable in eclipse variable list while "${version}" is properly send to pom when it is hard coded.
"${version}" is not resolving when send in goals section of run configuration
I'm facing problem when passing the eclipse variable from command line configuration.
in POM
<version>${version}</version>
<packaging>jar</packaging>
This is my build.gradle:
group 'whatever'
version '1.0.0-SNAPSHOT'
...
dependencies {
compile 'whatever:2.2.1-SNAPSHOT'
}
I want to automate releasing process, which includes the need to set both versions to particular values, e.g. 1.1.0 or 2.2.0 using command line only. Any kind of autoincrement is not an option.
With Maven, I'd do this using maven-versions-plugin:
mvn versions:set -DnewVersion=${WHATEVER_NEW_VERSION}
How can I do the same with Gradle? I only found this unanswered question. There must be some simple way to do that?
I ended up extracting version numbers to gradle.properties and updating them as part of the automated build script using sed:
sed -i -e \"/someVersionNumber=/ s/=.*/=${SOME_NEW_VERSION_NUMBER}/\" gradle.properties
It's what I want. Although for me, coming from the Maven background, this doesn't seem natural. I may research another alternative later.
Though not related to publishing, one way to pass command-line properties is as follows:
gradle -PWHATEVER_NEW_VERSION=2.0.0
Consider the following build.gradle snippet:
def newVersion = project."WHATEVER_NEW_VERSION"
println newVersion
See ~/utils/gradle/version.gradle in this project for another approach. It uses separate environment variables for major, minor, and incremental versions and then builds the string automatically. Because it resides in the gradle directory, it can simply be imported into build.gradle, which hides some boilerplate.
I successfully used Axion Release Plugin a couple of times and was very satisfied. Functionality-wise it comes the closest to what Maven's
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'm trying to execute a Gradle command-line task -setupDecompWorkspace to set up Minecraft Forge, but the task gets stuck on decompileMC. I've tried the first solution from this issue, but it didn't work. The second solution suggest setting the GRADLE_OPTS environment variable to -Xmx2G. I don't exactly know how to do this. After searching online for a couple of hours I am still found with no answer. Even the official Gradle documentation doesn't help. Do I need to declare the variable in the gradle.properties file, enter it as a command-line argument or something completely different?
-Xmx2G is a JVM command line parameter, if you want to set it as a Gradle property just add it to the gradle.properties file in your project root:
org.gradle.jvmargs=-Xmx2G
You can also find some more useful information here: https://docs.gradle.org/current/userguide/build_environment.html#sec:gradle_configuration_properties
I have a Maven job in Jenkins. Before the actual build step I have an "Execute shell" pre-build step. In that shell I set a variable:
REVISION=$(cat .build_revision)
I would like to use that variable in the Maven build job in "Goals and options":
clean install -Drevision=${REVISION}
But that does not work! The "Drevision" is set to "${REVISION}" not the actual value of ${REVISION}. Output:
Executing Maven: -B -f /home/gerrit/.jenkins/jobs/<job_name>/workspace/pom.xml clean install -Drevision=${REVISION}
It works with Jenkins environment variables:
clean install -Dbuild=${BUILD_NUMBER}
It sets "Dbuild" to the actual build number. Output:
Executing Maven: -B -f /home/gerrit/.jenkins/jobs/<job_name>/workspace/pom.xml clean install -Dbuild=54
My question: How to use a shell variable in Maven "Goals and options"??
EDIT:
I tried using Jenkins EnvInject Plugin to "Inject environment variables" after the pre-build shell, and my variable is now accessible by e.g. post-build shells, but it is still not available in Maven "Goals and options".
Then it is possible to set "Inject environment variables to the build process" using the EnvInject Plugin, which actually makes those variables available in Maven "Goals and options", but those are set right after SCM checkout, i.e. before pre-build steps, and do not support expression evaluations.
You're on the right track here, but missed a third feature of the EnvInject-Plugin: The "Inject environment variables" build step that can inject variables into following build steps based on the result of a script or properties.
We're using the EnvInject plugin just like that; A script sets up a resource and communicates its parameters using properties that are then propagated by the plugin as environment variables.
i.e. setting up a temporary database for the build:
I had a very similar problem, trying to compute a build version and inject it into the build. After running into all the same issues (not expanding, etc), I used the "Generate environment variables from script" option, which interprets the output as tag=value pairs into Jenkins variables. The script :
#generate a version code that is high enough to surpass previously published clients
val=`expr 150000 + $BUILD_NUMBER`
echo VERSION_CODE=$val
After this, I was able to inject $VERSION_CODE into maven as follows :
-Dbuild.vercode=${VERSION_CODE}
Hope that works for you.
This issue is caused by a bug in the Jenkins Maven Project Plugin as detailed in this bug report opened on 2012-06-22. The plugin has not yet been fixed as of version 2.1.
A fix has been proposed for the Maven Project Plugin, but has not yet been integrated. Here is the link to the pull request: https://github.com/jenkinsci/maven-plugin/pull/14
If you build the plugin yourself with the pull request patch applied, the variables are injected and made available to the "goals and options" field as expected.
I see there is an accepted answer, but for a newbie in Jenkins I found it hard to grasp it all. That's why I would add a bit more detail in this answer and show how I did it.
As #jjungnickel suggested you need to have EnvInject Plugin installed for Jenkins. Then in the Build section > Add build step you'll get option "Inject environment variables".
Basically the idea is:
Add variables you want to access later to a file (might be added by a shell script or it could be file from the file system).
Inject the file with the variables.
Use the variables.
Here a sample setup:
Since I want to use them in maven goal I need to check the Inject Build Variables checkbox.
Then at the end of the build I remove the file just because I want to keep the environment as it was before the build.
I think your best shot is to try the EnvInject plugin for this along with your initial pre-scm step.
You run the pre-scm as you already do.
You use the env inject to load the file for the main job's build steps
Consider loading your file's content (properties format) or execute a script which will load the file as you want and make a variable available for the rest of the job with the "Prepare an environment for the run" option.
I hope this helps.
I needed to resolve the variables before the injection was done so I put this in script content:
Example: (note it doesn't seem possible to simply export variables here so I wrote to files and the help section in jenkins seems to indicate this is expected)
git ls-tree --name-only -r ${sha1} | grep -v -c "*\.md" > diff.bak
git diff origin/master --shortstat | grep "1 files changed" && echo 1 > count.bak || echo 0 > count.bak
I then added this in the groovy script, using the output files I can create a map:
def procDiff = "cat $WORKSPACE/diff.bak".execute()
def procCount = "cat $WORKSPACE/count.bak".execute()
def diff = procDiff.text
def count = procCount.text
print "string val = $diff and count = $count "
if ("0".equals(diff) || !"1".equals(count)){
def map = ["GOAL": "clean verify"]
return map
} else {
def map = ["GOAL": "clean"]
return map
}
Then I could reference $GOAL in my maven build to conditionally trigger a "clean" or a "clean verify" based on the type of PR raised.