Some log messages in my build scripts are only relevant when the Gradle build is running on TeamCity. How do detect programmatically if the Gradle build is running on TeamCity or not?
This can be done using environment variables corresponding to TeamCity's server build parameters, quote:
Environment variable name
Description
TEAMCITY_VERSION
The version of the TeamCity server. This property can be used to determine if the build is run within TeamCity.
To do it in a Gradle script, method java.lang.System#getenv(java.lang.String) can be used:
boolean isOnTeamCity = System.getenv("TEAMCITY_VERSION") != null
In our CI environment, we currently have one build server (based on Atlassian Bamboo) and two SonarQube instances (versions 6.0 and 6.5). Initially, our CI server was configured to communicate with the 6.0 SonarQube instance. This has been configured in the /home/bamboo/.gradle/gradle.properties file on our CI server like this:
systemProp.sonar.host.url=<http url of SonarQube 6.0 instance>
systemProp.sonar.login=<username here>
systemProp.sonar.password=<password here>
Now we have another Gradle-based project running on our CI server which shall talk to the new SonarQube 6.5 instance. I tried configuring this but failed all the time.
Things I have done so far:
Added commandline arguments to gradle wrapper command:
I have tried adding -Dsonar.host.url=, -Dsonar.login=, -Dsonar.password= to the Gradle command. As this didn't seem to work, I have also tried to set commandline arguments as SonarQube system properties using -DsystemProp.sonar.host.url=, -DsystemProp.sonar.login=, -DsystemProp.sonar.password=. This didn't work either.
Added properties to the build.gradle file
- Added properties to the build.gradle file like this:
sonarqube {
properties {
property "sonar.host.url", "<http url of SonarQube 6.0 instance>"
property "sonar.login", "<username here>"
property "sonar.password", "<password here>"
...<other SonarQube analysis settings here>...
}
}
In all cases, the CI server talked to the wrong SonarQube instance (6.0). My question is, whether it is possible to configure a single project to talk to another SonarQube instance. As you have seen, we use Gradle 3.2.1 as a build tool. And we are using the org.sonarqube Gradle plugin too.
Thank you for any help.
André
Your first try did not work, because you set the system properties from the commandline, but setting it from the project properties later on resets the system properties to the configured values.
Your second try did not work, because the systemProp.sonar.login syntax is only suppored in gradle.properties files, not via -P commandline project properties.
Your third try did not work because the SonarQube scanner prefers the system property values over the value configured via the DSL, so that one can change what is configured in the build script with the help of local configuration.
You need to set the system properties in your build script manually, this then overwrite what was automatically set from the project property. Using the project gradle.properties file does not work as the user file overwrite the project file. So you need something like System.properties.'sonar.login' = '...' in your build script. You can either hard-code it there, or then use project properties that you can set in your gradle.properties file or via -P parameters.
Besides that, I'd never depend on having any configuration in Gradle User dir on a build server. Most buildservers use build agents that might run on distributed machines, so you would always have to make sure that all build agents are configured the same and so on. I'd always configure in the build setup of the build server the according configuration, either by setting system properties, or environment properties or commandline arguments.
Just my 2ct.
My build script depends on the MSBuild Community Task targets. I'd like to make this an agent requirement. How can this be done in TeamCity 8.x?
What you can do is add an Agent Requirement (Step 8 of your build Configuration)
Now immediately after doing this your build agent will be incompatible - that is because there is no such environment variable as MSBuildCommunityTasksPath - I've made this up because Community Tasks does not install any.
The next thing you need to do is log into the build agent PCs that do have Community Tasks installed and add this environment variable:
the path should be either
C:\Program Files (x86)\MSBuild\MSBuildCommunityTasks
or
C:\Program Files\MSBuild\MSBuildCommunityTasks
nb techincally it doesnt matter what you enter as this variable is just a flag indicating community tasks is installed
after you do this you need to restart your build agent
Now this paramter will be available in TeamCity and your build agent should be compatible. You can go to the Agents tab to check this. Agents -> <your agent> -> Agent parameters -> Environment Variables
Is it possible to specify build parameters ?
There is option for environment but it is not for build.
Something that will be put in command line as /p:MyParameter=MyValue
I have found a way to change a property in TeamCity:
##teamcity[setParameter name='ddd' value='fff']
But unfortunately this change only occurs for the current build. I want this change to be PERMANENT, but TeamCity only changes this for the current running build.
How do I make a permanent change to a system property in TeamCity?
The only solution using TeamCity 6.5 was to edit the Xml configuration file programmatically using a python script.
A build step calls the python script to change the variable during each build.
Use the REST API which is a feature of TeamCity 7.0
Api details here - http://confluence.jetbrains.com/display/TW/REST+API+Plugin#RESTAPIPlugin-BuildConfigurationAndTemplateSettings
I use this method to get and set properties from powershell during a build.