The build session state is managed by the `BuildSessionState` class.
An instance is created at the start of a Gradle invocation and discarded at the end of that invocation.

The build session state also includes "cross session" state that is shared with any "nested" sessions that need to be created.
This only happens when the `GradleBuild` task is used. You can mostly ignore the distinction between "cross session" and "build session" state.

### JVM platform

This is a platform that builds on the core and software platforms to add support for developing software that runs on the JVM.
This includes software that is implemented using Java, Kotlin or some other JVM language.

This platform provides specific support for Java, Groovy and Scala, and includes the foojay toolchain plugin.

### Extensibility platform

## Gradle runtimes

Gradle is also made up of several different processes that work together to "run the build", such as the Gradle daemon and the `gradlew` command.

Each process, or "runtime", applies different constraints to the code that runs in that process.
For example, each process has different supported JVMs and a different set of services available for dependency injection.

    types: [ closed ]

permissions: {}

jobs:
  check_pull_metadata:
    permissions:
      issues: write
      pull-requests: write
    runs-on: ubuntu-latest
    steps:
      # Check that PRs have proper metadata: labels and milestone
      # https://github.com/gradle/issue-management-action/blob/main/src/pull-metadata.ts
      - uses: gradle/issue-management-action@v1
        with:

  cancel-in-progress: true

env:
  # Set the DEVELOCITY_ACCESS_KEY so that Gradle Build Scans are generated
  DEVELOCITY_ACCESS_KEY: ${{ secrets.GRADLE_ENTERPRISE_ACCESS_KEY }}
  # Enable debug for the `gradle-build-action` cache operations
  GRADLE_BUILD_ACTION_CACHE_DEBUG_ENABLED: true

    - name: Setup Gradle
      uses: gradle/actions/dependency-submission@v3
      with:
        # Action runs a custom dependencies task that fails with config-cache on Gradle 8.7 (works with 8.6)
        additional-arguments: --no-configuration-cache
      env:
        # Exclude some projects and configurations that should not contribute to the dependency graph

on:
  issues:
    types: [ opened, unlabeled, closed ]

permissions: {}

jobs:
  check_issue_metadata:
    permissions:
      issues: write
    runs-on: ubuntu-latest
    steps:
      # Check that issues have proper metadata: labels and milestone
      # https://github.com/gradle/issue-management-action/blob/main/src/issue-metadata.ts
      - uses: gradle/issue-management-action@v1
        with:

      run: ./gradlew --no-configuration-cache --init-script .github/workflows/codeql-analysis.init.gradle -DcacheNode=us -S testClasses -Dhttp.keepAlive=false
      env:
        # Set the DEVELOCITY_ACCESS_KEY so that Gradle Build Scans are generated
        DEVELOCITY_ACCESS_KEY: ${{ secrets.GRADLE_ENTERPRISE_ACCESS_KEY }}
        # Potential stop-gap solution for ReadTimeout issues with the Gradle Build Cache

- Some base services that are available to code hosted by the runtime. This varies by runtime.
- Additional constraints. For example, the CLI client runtimes limit the libraries that are available to the code in that runtime, for performance reasons. 

Other modules and platforms define the services that they contribute to the runtime.