# You can define multiple automations in a .cm file, but each automation name should be unique
# within the file.  We keep each automation (or very closely related group of automations) in
# its own file.

on:
  - pr_created
  - commit

automations:

  summary_table:
    if:
      - {{ is.requested or not pr.author_is_org_member }}
      - {{ author.using_gitstream or not pr.author_is_org_member }}

            File(it, "src/integTest").exists() &&
                it.name != "distributions-integ-tests" && // distributions:integTest is part of Build Distributions
                it.name != "soak" // soak tests have their own test category
        }

        assertFalse(projectFoldersWithFunctionalTests.isEmpty())
        projectFoldersWithFunctionalTests.forEach {

# You can define multiple automations in a .cm file, but each automation name should be unique
# within the file.  We keep each automation (or very closely related group of automations) in
# its own file.

on:
  - pr_created
  - commit
  - comment_added

automations:

  summary_table_platforms:
    if:
      - {{ ('summary_table_platforms' | isEnabledAutomation(pr)) }}
    run:

# You can define multiple automations in a .cm file, but each automation name should be unique
# within the file.  We keep each automation (or very closely related group of automations) in
# its own file.

on:
  - pr_created
  - commit
  - comment_added

automations:

  # If someone adds a TODO, remind them about it by requesting removal
  includes_todos:
    if:

* To explain *rejected solutions*, for now, and future development, in case they are proposed again.

ADRs can be written by any team.
Like code, they should be reviewed by any other relevant teams.
The goal is not to *own* a decision, but to *share* it with other teams, and improve the build tool together.

### Format

The format for ADR should follow this template:

```markdown
# ADR-000X - Title

## Date

20YY-MM-DD

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.

The modules are arranged into several different "Gradle platforms".
A Gradle platform is a logical distribution that provides support for a specific kind of automation.

### Documentation

Provides cross-cutting Gradle documentation and samples, along with the infrastructure to write, test, publish and host the documentation.

## 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.

# You can define multiple automations in a .cm file, but each automation name should be unique
# within the file.  We keep each automation (or very closely related group of automations) in
# its own file.

on:
  - pr_created
  - commit
  - comment_added

automations:

  # Also post a comment that lists the best experts for the files that were modified.
  comment_experts:
    if:

# You can define multiple automations in a .cm file, but each automation name should be unique
# within the file.  We keep each automation (or very closely related group of automations) in
# its own file.

on:
  - pr_created
  - commit
  - comment_added

automations:

  javadoc_on_new_files:
    # Triggered for new Java files that lack Javadoc content.
    if:

Not every module contributes to every runtime.

The core-runtime module defines each runtime:

- The target JVM for the runtime. Each runtime has its own JVM compatibility constraints.
- Some base services that are available to code hosted by the runtime. This varies by runtime.