val ciGroup = "CI Lifecycle"

    register("quickTest") {
        description = "Run all unit, integration and cross-version (against latest release) tests in embedded execution mode"
        group = ciGroup
    }

    register("platformTest") {
        description = "Run all unit, integration and cross-version (against latest release) tests in forking execution mode"
        group = ciGroup
    }

Gradle tracks the state of each piece and transitions each piece through its lifecycle as the build runs.

A central part of the Gradle architecture is the "build state model", which holds the state for each piece and coordinates state transitions and other mutations. 
Most source code in Gradle is arranged by which part(s) of the build state model it acts on.
This affects the lifecycle of the code and the set of services available for dependency injection.

- **Size of Serialized Data:** Java serialization tends to produce larger serialized objects because it includes class metadata and other overhead.

- **Flexibility and Control:** Java serialization offers limited control over the serialization process, such as excluding certain fields, customizing naming conventions, and handling complex data structures more gracefully.

            parse(f, repository)
            counter++
        }

        //updating/modifying the metadata and making sure every type reference across the metadata is fully qualified
        //so, the superClassName, interfaces and types needed by declared properties and declared methods will have fully qualified name
        TypeNameResolver resolver = new TypeNameResolver(repository)

        """

# Each automation has an `if` key that defines conditions to run the automation,
# as well as a `run` key with the actions to do. All the conditions need to be true
# for the actions to run (there is an implicit AND relation between
# the conditions on each line).  Each condition is specified as a Jinja expression.  You
# can also use the constant `true` if you want to always run the actions.

 * but sometimes changes on release notes.md was brought to master and merged unnoticed,
 * e.g https://github.com/gradle/gradle/pull/25825
 *
 * This script is to check if there is any merge commit that brings changes from release branch to master.
 * Usage: groovy CheckBadMerge.groovy <commit1> <commit2> ...
 * If any "bad" merge commit is found, it will print the details and exit with non-zero code.
 */
class CheckBadMerge {

 * Doing it correctly would require running a Gradle build with the full
 * distribution and extracting the generated api jar from its Gradle user home,
 * slowing down building documentation.
 *
 * All this would be so much simpler if the Kotlin extensions to the Gradle API
 * were generated at build time instead.
 *
 * This is a first step to get the doc to be complete and will be revisited.
 */
@CacheableTask

class BuildDistributions(model: CIBuildModel, stage: Stage) : BaseGradleBuildType(stage = stage, init = {
    id("${model.projectId}_BuildDistributions")
    name = "Build Distributions"
    description = "Creation and verification of the distribution and documentation"

    applyDefaults(
        model,
        this,
        "packageBuild",
        extraParameters = buildScanTag("BuildDistributions") +

 * limitations under the License.
 */

package gradlebuild.testcleanup.extension

import org.gradle.api.provider.MapProperty
import org.gradle.api.provider.Property
import java.io.File


/**
 * An extension to work with {@see TestFilesCleanupService}.
 * We have to collect all information we need in this extension and pass them
 * to the build service.
 */