the documentation shows that I can configure this via the gui here: https://www.jetbrains.com/help/idea/project-security.html
Each time I have gradle perform :runIde it launches a new IDE instance and I have to reconfirm the trusted project directory.
Is there a gradle flag or setting somewhere in the plugin project to set this once for all?
I am using a kotlin build.gradle.kts file
*I have configured the trusted root in my 'Parent' IntelliJ IDEA that launches the task, but it seems, is sometimes not carried over. Alternatively I would like this to be available when operating from the CLI aswell.
*I am using the :clean command alongside the :runIde command, would this affect the settings being erased?
I'd like to build certain projects without the use of of Gradle daemon. I've read that this can be done either by command-line argument --no-daemon or by changing Gradle properties under .gradle/. I need to disable it for just some of the projects I build under the root project though.
Is it possible via settings.gradle/build.gradle settings or am I better off making custom build script?
You can simply add org.gradle.daemon=false to a gradle.properties file in the project root folder.
The daemon documentation mainly talks about disabling the daemon altogether on a machine but the gradle properties documentation indicates that the location where a property / value pair is declared is irrelevant, they are sourced from different location, with overwrite rules.
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.
There is a similar question here: Gradle properties not being read from ~/.gradle/gradle.properties but it does not solve my problem.
It seems to me that gradle is NOT reading my ~/.gradle/gradle.properties file.
I have a gradle.properties file in ~/.gradle, and it has properties needed to sign artifacts before uploading to maven central. It looks like this:
signing.keyId=12345678
signing.password=myPassword
signing.secretKeyRingFile=/home/me/.gnupg/secring.gpg
sonatypeUsername=me
sonatypePassword=myOtherPassword
When I try to build my project, it complains that there's no sonatypeUsername property, thus:
> Could not find property 'sonatypeUsername' on root project 'yourProject'.
Here's the relevant portion of my project's build.gradle:
uploadArchives {
repositories {
mavenDeployer {
// lots of non-interesting things here
repository(url: "https://oss.sonatype.org/service/local/staging/deploy/maven2/") {
authentication(userName: project.property("sonatypeUsername"), password: project.property("sonatypePassword"))
}
}
}
}
When I try to build the project with debugging, here's what I see regarding properties:
$ ./gradlew --stacktrace --debug build
[INFO] [o.g.BuildLogger] Starting Build
[DEBUG] [o.g.BuildLogger] Gradle user home: /home/me
[DEBUG] [o.g.BuildLogger] Current dir: /home/me/dev/yourProject
[DEBUG] [o.g.BuildLogger] Settings file: null
[DEBUG] [o.g.BuildLogger] Build file: null
[DEBUG] [o.g.i.b.BuildSourceBuilder] Starting to build the build sources.
[DEBUG] [o.g.i.b.BuildSourceBuilder] Gradle source dir does not exist. We leave.
[DEBUG] [o.g.i.DefaultGradlePropertiesLoader] Found env project properties: []
[DEBUG] [o.g.i.DefaultGradlePropertiesLoader] Found system project properties: []
[DEBUG] [o.g.a.i.a.m.DefaultLocalMavenRepositoryLocator] No local repository in Settings file defined. Using default path: /home/me/.m2/repository
[DEBUG] [o.g.i.ScriptEvaluatingSettingsProcessor] Timing: Processing settings took: 0.286 secs
[INFO] [o.g.BuildLogger] Settings evaluated using empty settings script.
[DEBUG] [o.g.i.ProjectPropertySettingBuildLoader] Looking for project properties from: /home/me/dev/yourProject/gradle.properties
[DEBUG] [o.g.i.ProjectPropertySettingBuildLoader] project property file does not exists. We continue!
[INFO] [o.g.BuildLogger] Projects loaded. Root project using build file '/home/me/dev/yourProject/build.gradle'.
The problem was that I made an assumption that wasn't true. If you look at section 14.2 of the gradle documentation, it says:
You can place a gradle.properties file in the Gradle user home directory (defined by the “GRADLE_USER_HOME” environment variable, which if not set defaults to USER_HOME/.gradle) or in your project directory.
My incorrect assumption was that USER_HOME just defaulted to the standard linux HOME environment variable. This is not true.
As soon as I export USER_HOME=$HOME in my ~/.bashrc everything works
By default, without setting GRADLE_USER_HOME, it should work. I tested it in v3.5.
But make sure if your are running it as the right user. For ex, if you do your ./gradlew build using sudo, then gradle.properties in your home folder will not be picked up.
To make sure the default gradle user home, you can run gradle with the --debug option and look out for the below line,
[DEBUG] [org.gradle.internal.buildevents.BuildLogger] Gradle user home:
I am using Windows and I was experiencing the same issue. I noticed that my ~/.gradle/gradle.properties file had a byte-order-marker (BOM) at the beginning and I think it had windows line endings (\r\n). I recreated my ~/.gradle/gradle.properties file by deleting it and then making a new one with vim with unix line endings (\n) with the same content as before and then it started working. I don't know if it was the BOM, line-endings, or the combination of the two that was causing the issue, but I thought I should share this in case someone else has the same cause for this issue.
A quick and dirty solution is just to simply put the gradle.properties right next to your build.gradle, that will guarantee it will be read. I realize this doesn't solve a single centralized source of common properties, but at least it's something.
I did check Proxy Settings in Android Studio and i had No Proxy selected.
I did Invalidate Cache and Restart with no luck.
I added an exception in Firewall, still no luck.
In project gradle.properties i have no proxy configurations. Its empty, only comments.
In a previous version of Android Studio i had enabled Global Proxy Setting and it was a file stored in my user profile %userprofile%\.gradle\gradle.properties
Removing proxy lines in this file, solved my issue. I had to restart Android Studio to make it work.
:)
I myself stumbled upon this question when I was struggling with apk building via gradlew.
I tried setting Gradle_user_home earlier for the mentioned error in question, but it was of no use, below solution worked for me.
I have below configuration for gradle-wrapper.properties :
*distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-5.4.1-all.zip*
gradlew itself at run time downloads the correct distribution of gradle from above config (distributionUrl). Nothing else is required.
I faced the same issue and solved it by using gradle binary, to build, instead of wrapper that comes with android project. You can install gradle from here: https://docs.gradle.org/current/userguide/installation.html#installation
Then used system-wide gradle to build, while on project root, instead of wrapper, like ex:
$ gradle installDebug
I made a different mistake. Why did i set up this field in "intelligent idea"? :) However when i wrote correct value in this field I get correct reading gradle.properties from .gradle
some setting in Idea
Oh I noted that the "project property file does not exists. We continue!" is shown because the script will search for gradle properties in different routes.
it will check both in root/gradle.properties and in root/app/gradle.properties, so it will only add the ones from the one found and display the "error" from the other one.
However in the log you can actually see the properties that were added from the read files:
Adding project properties (if not overwritten by user properties): [android.nonTransitiveRClass, kotlin.code.style, org.gradle.jvmargs, android.useAndroidX]
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.