// Disallow Web UI changes to TeamCity settings
        param("teamcity.ui.settings.readOnly", "true")
        // Avoid rebuilding same revision if it's already built on another branch
        param("teamcity.vcsTrigger.runBuildOnSameRevisionInEveryBranch", "false")
        param("env.DEVELOCITY_ACCESS_KEY", "%ge.gradle.org.access.key%;%ge-td-dogfooding.grdev.net.access.key%")

        text(
            "additional.gradle.parameters",

    get() = settingsRoot.id.toString().substringAfter("Gradle")

data class VersionedSettingsBranch(val branchName: String) {
    /**
     * 0~23.
     * To avoid nightly promotion jobs running at the same time,
     * we run each branch on different hours.
     * master - 0:00
     * release - 1:00
     * release6x - 2:00
     * release7x - 3:00
     * ...
     * releaseNx - (N-4):00
     */

    else -> actualBranch
}

/**
 * The build environment.
 *
 * WARNING: Every val in here must not change for they same daemon. If it does, changes will go undetected,
 *          since this whole object is kept in the classloader between builds.
 *          Anything that changes must be in a val with a get() method that recomputes the value each time.

val Project.buildBranch: Provider<String>
    get() = environmentVariable(BUILD_BRANCH).orElse(currentGitBranchViaFileSystemQuery())


/**
 * The logical branch.
 * For non-merge-queue branches this is the same as {@link #buildBranch}.
 * For merge-queue branches, this is the base branch.
 *
 * For example, for the merge queue branch "gh-readonly-queue/master/pr-12345-1a2b3c4d" the logical branch is "master".
 */

    doesNotContain("teamcity.agent.name", "EC2")
}

/**
 * We have some "shared" host where a Linux build agent and a Windows build agent
 * both run on the same bare metal. Some builds require exclusive access to the
 * hardware resources (e.g. performance test).
 */
fun Requirements.requiresNotSharedHost() {
    doesNotContain("agent.host.type", "shared")
}

/**
 * This is an undocumented location that forbids anonymous access.

            // 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"
                param("locks-param", "WebsiteReleasesXml writeLock")
            }
        }
    }

Historically, Gradle has shipped with some Groovy types in very prominent APIs.
This required the Kotlin DSL to add special integration to work with Groovy closures.
This has also forced plugins written in languages other than Groovy to use Groovy types for some APIs.

When the Kotlin DSL was introduced, we made an effort to add non-Groovy equivalents for all APIs.

The main logic with ADRs is to describe (architectural) decisions made:

* To provide best practices and solutions we (as the *build tool* team) want to promote.
* To avoid asking the same thing multiple times during code review.
* To explain *rejected solutions*, for now, and future development, in case they are proposed again.

ADRs can be written by any team.

[
	{
		"buckets":[
			{
				"parallelizationMethod":{
					"name":"TestDistribution"
				},
				"subprojects":[
					"dependency-management"
				]
			},
			{
				"parallelizationMethod":{
					"name":"TestDistribution"
				},
				"subprojects":[
					"configuration-cache"
				]
			},
			{
				"parallelizationMethod":{
					"name":"TestDistribution"
				},
				"subprojects":[
					"tooling-api"
				]

name: IDE Experience team notifier
run-name: Notify the IDE Experience team about relevant issues
on:
  issues:
    types:
      - labeled

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: