> **NOTE:** Do **NOT** run `gradle build` on the local development environment,
> even if you have Gradle or Develocity build caching enabled for the project.
> The Gradle Build Tool repository is massive, and it will take ages to build on
> a local machine without necessary parallelization and caching.
> The full test suites are executed on the CI instance for multiple configurations,

                            // If we don't clean that up there might be leftover json files from other report builds running on the same machine.
                            """
                            results/performance/build/test-results-*.zip!performance-tests/report/css/*.css => $performanceResultsDir/
                            $perfResultArtifactRule

/**
 * Clean up daemon log files produced in integration tests.
 */
fun FileSystemOperations.removeDaemonLogFiles(dir: Directory) {
    if (dir.asFile.isDirectory) {
        val daemonLogFiles = dir.asFileTree.matching {
            include("**/*.log")
        }
        delete { delete(daemonLogFiles) }
    }

import org.gradle.internal.util.PropertiesUtils
import org.gradle.util.internal.VersionNumber
import org.gradle.work.DisableCachingByDefault
import java.util.Properties


@DisableCachingByDefault(because = "Not worth caching")
abstract class UpdateInitPluginTemplateVersionFile : DefaultTask() {

    private
    val devSuffixes = arrayOf(
        "-SNAP\\d+",
        "-SNAPSHOT",
        "-alpha.*\\d+",
        "-beta.*\\d+",

                                "org.gradle.performance.regression.corefeature.FileSystemWatchingPerformanceTest",
                                "assemble for non-abi change with file system watching and configuration caching"
                            ),
                            it
                        )
                    }
                )
            )
        ),
        Stage(

val Project.testJavaVendor: Provider<JvmVendorSpec>
    get() = propertyFromAnySource(TEST_JAVA_VENDOR).map { vendorName -> VENDOR_MAPPING.getOrElse(vendorName) { -> JvmVendorSpec.matching(vendorName) } }


val Project.testJavaVersion: String
    get() = propertyFromAnySource(TEST_JAVA_VERSION).getOrElse(JavaVersion.current().majorVersion)


val Project.testSplitIncludeTestClasses: String

# ADR-0002 - Avoid using Java serialization

## Date

2012-12-01

## Context

In Gradle we often need to serialize in-memory objects for caching, or to transmit them across process barriers, etc.
Java serialization is one way to implement this, however, despite its simplicity of implementation, it has several drawbacks:

- **Performance:**
Java's built-in serialization mechanism is often slower compared to other serialization solutions.

    `java-test-fixtures`
    groovy
    id("gradlebuild.dependency-modules")
}

// The below mimics what the java-library plugin does, but creating a library of test fixtures instead.

sourceSets.matching { it.name.endsWith("Test") }.all {
    // the 'test' (with lower case 't') source set is already configured to use test fixtures by the JavaTestFixturesPlugin
    configurations[implementationConfigurationName].dependencies.add(

        val compileTasks = project.tasks.matching {
            it is JavaCompile || it is GroovyCompile
        }
        dependsOn(compileTasks)
    }

    tasks.register("compileAllProduction") {
        description = "Compile all production source code, usually only main and testFixtures."
        val compileTasks = project.tasks.matching {

- **Configuration**: Allows the build structure and work, such as tasks, to be specified. This includes the project model, the DSL and so on.
- **Execution**: Runs the work efficiently. This includes scheduling, execution, caching and so on.

#### Software development platform

This is a general purpose platform that builds on the core automation platform to add support for the automation of software development.