Skip to content
Merged
Show file tree
Hide file tree
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -206,6 +206,18 @@ Alternative manual steps for IntelliJ.
3. Navigate to the file `build-conventions/formatterConfig.xml`
4. Click "OK"

#### Options

When importing to IntelliJ, we offer a few options that can be used to
configure the behaviour of the import:

| Property | Description | Values (* = default) |
|--------------------------------------------|------------------------------------------------------------------------------------------------------|----------------------|
| `org.elasticsearch.idea-configuration-cache` | Should IntelliJ enable the Gradle Configuration cache to speed up builds when generating run configs | *`ture`, `false` |
| `org.elasticsearch.idea-delegate-to-gradle` | Should IntelliJ use Gradle for all generated run / test configs or prompt each time | `true`, *`false` |

These options can be set anywhere on the Gradle config path including in `~/.gradle/gradle.settings`
Copy link
Contributor

@breskeby breskeby May 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should just use ~/.gradle/gradle.properties for this as there's build-in support to read props in gradle from that file. I'm surprised gradle.settings even works. I guess a typo?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope not a typo. Stuff in ~/.gradle/gradle.settings applies globally for the current user but the repo specific file would work too. I guess it comes down to if we think it would be useful for it to apply to multiple projects or not (IE would I like to to just globally apply to stateful and serverless assuming they share this build code?).

I could be convinced either way or, perhaps we just document the options here and leave it up to the user if they want it applied globally or just per repo?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just realised this is totally a typo -.- Updating now


### REST endpoint conventions

Elasticsearch typically uses singular nouns rather than plurals in URLs.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -180,6 +180,7 @@ if (providers.systemProperty('idea.active').getOrNull() == 'true') {
// this path is produced by the extractLibs task above
String testLibraryPath = TestUtil.getTestLibraryPath("${elasticsearchProject.left()}/libs/native/libraries/build/platform")
def enableIdeaCC = providers.gradleProperty("org.elasticsearch.idea-configuration-cache").getOrElse("true").toBoolean()
def delegateToGradle = providers.gradleProperty("org.elasticsearch.idea-delegate-to-gradle").getOrElse("false").toBoolean()
idea {
project {
vcs = 'Git'
Expand All @@ -188,7 +189,7 @@ if (providers.systemProperty('idea.active').getOrNull() == 'true') {
settings {
delegateActions {
delegateBuildRunToGradle = false
testRunner = 'choose_per_test'
testRunner = delegateToGradle ? 'gradle' : 'choose_per_test'
}
taskTriggers {
afterSync tasks.named('configureIdeCheckstyle'),
Expand Down