fun buildTimestampFrom(provider: Provider<String>) {
        buildTimestamp = provider.map { buildTimestampString -> timestampFormat.parse(buildTimestampString) }
    }

    @TaskAction
    fun generate() {
        if (promotionBuild.get()) {
            logger.logBuildVersion()
        }
        val file = receiptFolder.file(buildReceiptLocation).get().asFile.also {
            it.parentFile.mkdirs()
        }

author:
  using_gitstream: {{ (pr.author | isEnabledUser ) }}

# Perhaps a task could generate this list from the CODEOWNERS, or both this and CODEOWNERS could be generated from different single source of truth?
# Keys like `- build_infrastructure:` do not mean anything, they just need to be unique

<!-- This is a generated file. Use `./gradlew :architectureDoc` to generate -->
# Gradle platform architecture
```mermaid
    graph TD

subgraph core["core platform"]

core_runtime["core-runtime module"]
style core_runtime stroke:#1abc9c,fill:#b1f4e7,stroke-width:2px;

core_configuration["core-configuration module"]
style core_configuration stroke:#1abc9c,fill:#b1f4e7,stroke-width:2px;

core_execution["core-execution module"]

When the Kotlin DSL was introduced, we made an effort to add non-Groovy equivalents for all APIs.
This has been mostly done, but there remain a few holdouts (fixing these is out of scope).

To keep the Groovy DSL ergonomic, we generate methods as necessary from the non-Groovy equivalents.

Doing this provides the following specific benefits:
- **Reduce the API surface** - We no longer need to maintain two methods.

    @Input
    val projects = projectDependencies.elements.map { it.map { it.toGradleModuleName() }.sorted() }

    @get:OutputFile
    abstract val manifestFile: RegularFileProperty

    @TaskAction
    fun generate() {
        ReproduciblePropertiesWriter.store(createProperties(), manifestFile.get().asFile)
    }

    private
    fun createProperties() = Properties().also { properties ->

import java.io.File


/**
 * Helper for reflective usage by `KotlinExtensionsForGradleApiFacade`.
 */
class PluginIdExtensionsFacade {
    @Suppress("UNCHECKED_CAST")
    fun generate(parameters: Map<String, Any>) {
        writeBuiltinPluginIdExtensionsTo(
            parameters["file"] as File,
            parameters["gradleJars"] as Iterable<File>,

// Required due to: https://github.com/gradle/gradle/issues/13278
testFixturesRuntimeElements.extendsFrom(testFixturesRuntimeOnly)

// do not attempt to find projects when the plugin is applied just to generate accessors
if (project.name != "gradle-kotlin-dsl-accessors" && project.name != "test" /* remove once wrapper is updated */) {
    dependencies {
        testFixturesApi(project(":internal-testing"))
        // platform

<!-- 
  -- Note: this file contains a generated diagram. Use `./gradlew :architectureDoc` to generate 
  -->

# Gradle platform architecture

Gradle is arranged into coarse-grained components called "architecture modules" and "platforms".
See [ADR4](standards/0004-use-a-platform-architecture.md) for a definition of these terms.

The diagram below shows the current set of architecture modules and platforms:

including but not limited to: User Manual, DSL Reference and Javadoc.
This information is used to generate documentation for each Gradle version
on [docs.gradle.org](https://docs.gradle.org/).
The documentation is mostly implemented in Asciidoc
though we use GitHub-flavored Markdown for internal documentation too.

You can generate docs by running `./gradlew :docs:docs`.

      "coverage" : {
        "per_commit" : [ "linux" ]
      }
    } ]
  }, {
    "testId" : "org.gradle.performance.regression.java.JavaDependencyReportPerformanceTest.generate dependency report",
    "groups" : [ {
      "testProject" : "largeJavaMultiProject",
      "coverage" : {
        "per_day" : [ "linux" ]
      }
    }, {
      "testProject" : "largeMonolithicJavaProject",