"precondition-tester",
					"problems",
					"problems-api",
					"process-services",
					"publish",
					"reporting",
					"resources",
					"resources-gcs",
					"resources-http",
					"resources-s3",
					"resources-sftp",
					"samples",
					"signing",
					"snapshots",
					"testing-base",
					"toolchains-jvm",
					"tooling-api",
					"version-control",

For example, each process has different supported JVMs and a different set of services available for dependency injection.
While a lot of Gradle source code runs only in the Gradle daemon, not all of it does and so, when working on some source code it is important to be aware of the runtimes in which it will run.

See [Gradle runtimes](runtimes.md) for a list of these runtimes and more details.

## Build state model

      - uses: actions/upload-artifact@v4
        with:
          name: build-receipt.properties
          path: platforms/core-runtime/base-services/build/generated-resources/build-receipt/org/gradle/build-receipt.properties
    outputs:
      matrix: ${{ steps.setup-matrix.outputs.matrix }}
      sys-prop-args: ${{ steps.determine-sys-prop-args.outputs.sys-prop-args }}

  sanity-check:

        }

        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 {

    "name": "resources-http",
    "path": "platforms/software/resources-http",
    "unitTests": true,
    "functionalTests": true,
    "crossVersionTests": false
  },
  {
    "name": "resources-s3",
    "path": "platforms/software/resources-s3",
    "unitTests": true,
    "functionalTests": true,
    "crossVersionTests": false
  },
  {
    "name": "resources-sftp",
    "path": "platforms/software/resources-sftp",

This guide explains how to contribute to the core Gradle components, 
extensions and documentation located in this repository.
For other extensions and components, see the 
[Gradle Community Resources](https://gradle.org/resources/).

This guide will help you to...

* maximize the chance of your changes being accepted
* work on the Gradle code base
* get help if you encounter trouble

## Before you start

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.

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

      "coverage" : {
        "per_commit" : [ "linux" ]
      }
    } ]
  }, {
    "testId" : "org.gradle.performance.regression.nativeplatform.NativeBuildPerformanceTest.assemble with source file change",
    "groups" : [ {
      "testProject" : "bigCppApp",
      "coverage" : {
        "per_day" : [ "linux" ]
      }
    }, {
      "testProject" : "bigCppMulti",
      "coverage" : {

                            public abstract Property<String> getSourceCompatibility();
                        }
                    """
                )
                withFile(
                    "resources/upgraded-properties.json",
                    """
                        [{
                            "containingType": "com.example.Task",
                            "methodName": "getSourceCompatibility",

        worker3["Worker process"]
        daemon --> worker3
    
```

These are all Java processes. Each process has a corresponding "runtime".
All source code in Gradle is written to target one or more of these runtimes.
Most source code targets the daemon and the remaining code either targets a single runtime, for example the Gradle client, or is shared across multiple runtimes.

## Composition by architecture modules