This may help you better understand and contribute to Gradle.

### Debugging Gradle

You can debug Gradle by adding `-Dorg.gradle.debug=true` to the command-line. Gradle will wait for you to attach a debugger at `localhost:5005` by default.

If you made changes to build logic in the `build-logic` included build, you can run its tests by executing `./gradlew :build-logic:check`.

          distribution: 'zulu'
          java-version: 17

      - name: Setup Gradle
        uses: gradle/actions/setup-gradle@v4

      - name: Build okcurl
        run: ./gradlew okcurl:nativeImage

      - name: Setup Gradle
        uses: gradle/actions/setup-gradle@v4

      - name: Build ConsoleLauncher
        run: ./gradlew -PgraalBuild=true native-image-tests:nativeImage

      - name: Run Checks

import org.junit.jupiter.api.Tag
import org.junit.jupiter.api.Test
import org.junit.jupiter.api.extension.RegisterExtension
import org.opentest4j.TestAbortedException

/**
 * Run with "./gradlew :android-test:connectedCheck -PandroidBuild=true" and make sure ANDROID_SDK_ROOT is set.
 */

@Tag("Slow")
class OkHttpTest {
  @Suppress("RedundantVisibilityModifier")
  @JvmField
  @RegisterExtension

GraalVM is an exciting new platform and we're eager to adopt it. The startup time improvements over
the JVM are particularly impressive. Try it with okcurl:

```
$ ./gradlew okcurl:nativeImage
$ ./okcurl/build/graal/okcurl https://cash.app/robots.txt
```

This is our first release that supports GraalVM. Our code on this platform is less mature than JVM

warranty or additional liability. END OF TERMS AND CONDITIONS META-INF/MANIFEST.MF Manifest-Version: 1.0 Implementation-Title: Gradle Wrapper org/gradle/cli/CommandLineArgumentE.class package org.gradle.cli; public final synchronized class CommandLineArgumentE extends RuntimeException { public void CommandLineArgumentE(String); } org/gradle/cli/CommandLineOption.class package org.gradle.cli; public final synchronized class CommandLineOption { public final java.util.HashSet options; public Class argumentType;...

<component name="InspectionProjectProfileManager">
  <profile version="1.0">
    <option name="myName" value="Gradle" />
    <inspection_tool class="21f28a86-2ba8-3048-9ce1-b6f10d4d4a12" enabled="true" level="WEAK WARNING" enabled_by_default="true" editorAttributes="INFO_ATTRIBUTES" />
    <inspection_tool class="73cd39e8-e54e-3a38-ad1b-b883fff4b1eb" enabled="true" level="WEAK WARNING" enabled_by_default="true" editorAttributes="INFO_ATTRIBUTES" />

    )
    fun `publish milestone build type runs three gradle invocations`(branch: String, promoteTaskName: String) {
        val model = setupModelFor(branch)
        val nightlySnapshot = model.findBuildTypeByName("Release - Milestone")

        val steps = nightlySnapshot.steps.items
        assertEquals(3, steps.size)

The Gradle codebase has evolved over time and has a mixture of simple getter/setter methods, Provider API and things in between.  It can be hard to follow best practices because Gradle provided types are reused in unexpected ways and extended by third party plugins.

Given these constraints, we cannot always follow best practices.  This ADR proposes the way we should handle the use of Provider APIs in the gradle/gradle codebase.

## Decision

    "linux" : 428
  } ]
}, {
  "scenario" : "org.gradle.performance.experiment.maven.JavaTestGradleVsMavenPerformanceTest.assemble for non-abi change (Gradle vs Maven)",
  "durations" : [ {
    "testProject" : "mediumJavaMultiProject",
    "linux" : 84
  }, {
    "testProject" : "mediumMonolithicJavaProject",
    "linux" : 81
  } ]
}, {

    "testId" : "org.gradle.performance.experiment.declarativedsl.DeclarativeDslFirstUsePerformanceTest.clean checkout",
    "groups" : [ {
      "testProject" : "largeEmptyMultiProjectDeclarativeDsl",
      "coverage" : {
        "per_day" : [ "linux", "macOs", "windows" ]
      }
    } ]
  }, {
    "testId" : "org.gradle.performance.experiment.declarativedsl.DeclarativeDslFirstUsePerformanceTest.cold daemon",
    "groups" : [ {