There are 3 subprojects in the TeamCity project hierarchy: `Check` for Gradle builds, `Promotion` for releasing Gradle versions, `Util` for miscellaneous utilities.

## Develop and verify

After you make a change, you can run `mvn clean teamcity-configs:generate` to generate and verify the generated TeamCity configuration XMLs.

You also need to run `mvn clean verify` with Java 8 before committing changes.

        excludedPackages.add("org.gradle.platform.base.test");
        return excludedPackages;
    }

    // TODO: This doesn't really make sense to be part of the user manual generation, but it's so tied up into it
    // it's left here for a future project.

    git config user.email ******@****.***

#### Import Gradle into IntelliJ

To import Gradle into IntelliJ:
- Open the `build.gradle.kts` file with IntelliJ and choose "Open as Project"
- Make sure "Create separate module per source set" is selected
- Make sure  "Use default gradle wrapper" is selected
- Select a Java 11 VM as "Gradle JVM"
- In the "File already exists" dialogue, choose "Yes" to overwrite

    #    and modify them (or add more) to build your code if your project
    #    uses a compiled language

    #- run: |
    #   make bootstrap
    #   make release

    - name: Perform CodeQL Analysis
      uses: github/codeql-action/analyze@v3
      with:
        config-file: ./.github/codeql/codeql-config.yml

    - name: Cleanup Gradle Cache

## Architecture decision records (ADRs)

The Gradle team uses ADRs to record architectural decisions that the team has made.

See [Architecture decisions records](standards) for the list of ADRs.

## Structure

Each platform and module has its own source directory under [platforms/](../platforms).
In these source directories, you will find the Gradle projects that make up the platform or module.

The platforms and modules are defined using a DSL in [settings.gradle.kts](../settings.gradle.kts)

                // Here we check the existence of `@Flaky` annotation to make sure nobody use that annotation in `distributions-integ-tests` subproject.
                name = "MAKE_SURE_NO_@FLAKY_IN_DISTRIBUTIONS_INTEG_TESTS"
                executionMode = BuildStep.ExecutionMode.ALWAYS

                    <pre>${prettyPrintJson(acceptanceJson)}</pre>
                  </div>
                </div>
                </p>
                <p>
                If change was made on the `release` branch but hasn't yet been published to the baseline version, update the baseline version:

# its own file.

on:
  - pr_created
  - commit
  - comment_added

automations:

  # Add a label that indicates how many minutes it will take to review the PR and categorizes it
  estimated_time_to_review:
    if:
      - {{ ('estimated_time_to_review' | isEnabledAutomation(pr)) }}
    run:
      - action: add-label@v1

We use *Specification* and *Discovery* documents stored in Google Drive, but they present some downsides:

* They are rarely updated after creation and initial review, and then become hard to follow, especially after important decisions are made
* They are not synced with the code to reflect the eventual solution that is committed
* Google Docs is not a "code-oriented" tool, like asciidoc can be
* Review in Google Docs is not as simple as a PR code review in GitHub