Each platform provides support for some kind of automation, such as building JVM software or building Gradle plugins.
Most platforms typically build on the features of other platforms.

By understanding the Gradle platforms and their relationships, you can get a feel for where in the Gradle source a particular feature might be implemented.

See [Gradle platform architecture](platforms.md) for a list of the platforms and more details.

## Gradle runtimes

    }
}

fun BaseGradleBuildType.tcParallelTests(numberOfBatches: Int) {
    if (numberOfBatches > 1) {
        params {
            param("env.TEAMCITY_PARALLEL_TESTS_ENABLED", "1")
        }
        features {
            parallelTests {
                this.numberOfBatches = numberOfBatches
            }
        }
    }
}

fun BuildFeatures.publishBuildStatusToGithub() {
    commitStatusPublisher {

    }

    vcs {
        root(AbsoluteId(VersionedSettingsBranch.fromDslContext().vcsRootId()))
        checkoutMode = CheckoutMode.ON_AGENT
        branchFilter = branchesFilterExcluding()
    }

    features {
        enablePullRequestFeature()
    }

    requirements {
        requiresOs(os)
        requiresArch(os, arch)
    }

    failureConditions {

## GitHub docs: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
##
## CODEOWNERS style rules:
## 1. Prefer team ownership over individual user ownership.
## 2. GBT-related team should be listed first.
## 3. Try to keep paths alphabetically sorted within visual groups.
## 4. List individual owners last.
##

# bt-unassigned-maintainers must be the first owner

        }

        features {
            // https://www.jetbrains.com/help/teamcity/shared-resources.html#Viewing+Shared+Resources+Usage
            // https://blog.jetbrains.com/teamcity/2013/05/explaining-the-shared-resources-plugin/
            // we only allow 1 promotion job running at the same time to avoid website xml conflicts
            feature {
                type = "JetBrains.SharedResources"

* Create integration tests that exercise a Gradle build for the bug/feature. 
* Annotate tests that correspond to a bug on GitHub (`@Issue("https://github.com/gradle/gradle/issues/2622")`).
* Add documentation to the User Manual and DSL Reference (under [platforms/documentation/docs/src/docs](platforms/documentation/docs/src/docs/)).

## Decision

Organize the Gradle code base into a set of coarse-grained "architecture modules".
An architecture module is responsible for providing a coherent set of features and:

- Provides a set of APIs and services for use from outside the module.
- Has a private implementation.
- Is owned by a single team. A team may own multiple architecture modules.

    requirements {
        // Gradleception is a heavy build which runs ~40m on EC2 agents but only ~20m on Hetzner agents
        requiresNotEc2Agent()
        requiresNotSharedHost()
    }

    features {
        publishBuildStatusToGithub(model)
    }

    dependencies {
        // If SanityCheck fails, Gradleception will definitely fail because the last build step is also sanityCheck

class SmokeIdeTests(model: CIBuildModel, stage: Stage) : BaseGradleBuildType(stage = stage, init = {
    id(buildTypeId(model))
    name = "Smoke Ide Tests"
    description = "Tests against IDE sync process"

    features {
        publishBuildStatusToGithub(model)
    }

    requirements {
        // These tests are usually heavy and the build time is twice on EC2 agents
        requiresNotEc2Agent()
    }

            param("performance.db.username", "tcagent")
            param("performance.channel", performanceTestSpec.channel())
        }

        features {
            publishBuildStatusToGithub(model)
        }

        val performanceResultsDir = "perf-results"
        val performanceProjectName = "performance"