},
			{
				"parallelizationMethod":{
					"name":"TestDistribution"
				},
				"subprojects":[
					"tooling-api",
					"worker-processes",
					"files",
					"java-language-extensions",
					"build-cache-packaging",
					"build-operations",
					"precondition-tester",
					"tooling-api-builders",
					"hashing",
					"base-services-groovy",
					"kotlin-dsl-provider-plugins"
				]
			},

permissions: {}

jobs:
  send-slack-notification:
    if: ${{ github.event.label.name == 'in:ide' || github.event.label.name == 'in:eclipse-plugin' || github.event.label.name == 'in:idea-plugin' || github.event.label.name == 'in:tooling-api' }}
    runs-on: ubuntu-latest
    steps:
      - name: Send Slack notification about issues with specific labels
        id: slack
        uses: slackapi/slack-github-action@v1.23.0
        with:

platforms/core-configuration/kotlin-dsl-provider-plugins/   @gradle/bt-kotlin-dsl-maintainers
platforms/core-configuration/kotlin-dsl-tooling-builders/   @gradle/bt-kotlin-dsl-maintainers
platforms/core-configuration/kotlin-dsl-tooling-models/     @gradle/bt-kotlin-dsl-maintainers

# Core automation platform (Declarative DSL)
platforms/core-configuration/declarative-dsl-api/               @gradle/bt-declarative-dsl

    "crossVersionTests": false
  },
  {
    "name": "kotlin-dsl-tooling-builders",
    "path": "platforms/core-configuration/kotlin-dsl-tooling-builders",
    "unitTests": true,
    "functionalTests": false,
    "crossVersionTests": true
  },
  {
    "name": "kotlin-dsl-tooling-models",
    "path": "platforms/core-configuration/kotlin-dsl-tooling-models",
    "unitTests": false,
    "functionalTests": false,

# TODO: It would be very nice to avoid having this list somehow, but it needs to be defined in YAML and not in JS for the looping template to work
# Keys like `- build_infrastructure:` do not mean anything, they just need to be unique
# The `name:` field specifies the platform label, e.g. `name: build_infrastructure` => `platform:build_infrastructure` label

    "groups" : [ {
      "testProject" : "largeJavaMultiProjectNoBuildSrc",
      "coverage" : {
        "per_day" : [ "linux" ]
      }
    } ]
  }, {
    "testId" : "org.gradle.performance.regression.java.JavaConfigurationCachePerformanceTest.assemble storing configuration cache state with hot daemon",
    "groups" : [ {

### Enterprise integration

Provides cross-cutting integration with Gradle's commercial product.

### IDE integration

Provides cross-cutting integration with IDEs and other tooling.

### Build infrastructure

Provides build logic, libraries, test suites and infrastructure to support developing and releasing Gradle.

### Documentation

* How will it roughly be implemented? We'll happily provide code pointers to save you time.

We may ask you to answer these questions directly in the GitHub issue or (for large changes) in a shared Google Doc.

If you are looking for good first issues, take a look at the list of [good first issues](https://github.com/gradle/gradle/labels/good%20first%20issue) that should be actionable and ready for a contribution.

### Security vulnerabilities

- CLI client. This is the `gradle` or `gradlew` command, and is responsible for locating, starting and interacting with the Gradle daemon, potentially downloading the Gradle distribution. 
- Tooling API client. This a library that is embedded into applications, such as IDEs or CI agents, that allows them to act as a Gradle client.