authenticator.setMaxGroupDepth(5);

        // Test with depth one before the limit - should attempt to process
        // Will fail due to null user, but verifies depth check passes
        try {
            authenticator.getParentGroup(null, "test-id", 4);
            // If we reach here without NullPointerException, depth check passed
        } catch (NullPointerException e) {

        if (loginCredential == null) {
            if (ssoManager.available()) {
                if (logger.isDebugEnabled()) {
                    logger.debug("SSO is available but no user found.");
                }
                saveError(messages -> messages.addErrorsSsoLoginError(GLOBAL));
            }
            if (logger.isDebugEnabled()) {

        int statusCode = response.getStatusCode();
        // Accept either 200 (success) or other status codes based on implementation
        assertTrue(statusCode == 200 || statusCode == 400, "Status code should be 200 or 400, but was " + statusCode);

        if (statusCode == 200) {
            JsonPath jsonPath = JsonPath.from(response.asString());
            assertEquals(Integer.valueOf(0), jsonPath.get("response.status"));
        }
    }

                .when()
                .put(getApiPath() + "/upload");

        int statusCode = response.getStatusCode();
        assertTrue(statusCode == 200 || statusCode == 400, "Status code should be 200 or 400, but was " + statusCode);

        if (statusCode == 200) {
            JsonPath jsonPath = JsonPath.from(response.asString());
            assertEquals(Integer.valueOf(0), jsonPath.get("response.status"));
        }
    }

import java.util.stream.*;

/**
 * See https://github.com/gradle/gradle-private/issues/3919
 *
 * When merging `releaseX` branch into `master`, we should only use the release note from the `master` branch,
 * but sometimes changes on release notes.md was brought to master and merged unnoticed,
 * e.g https://github.com/gradle/gradle/pull/25825
 *

## How the configuration works

We use Kotlin portable DSL to store TeamCity configuration, which means you can easily create a new pipeline
based on a specific branch. Currently, we have two pipelines: `master` and `release`, but you can easily create
and test another isolated pipeline from any branch. 

We'll explain everything via an example. Let's say you make some changes on your branch `myTestBranch`

            requiresNotSharedHost()
        }

    /*
     To avoid unnecessary rerun, what we do here is a bit complicated:

     1. Build a Gradle distribution with a fixed timestamp and hash it, but never use this distribution.
     2. Build a Gradle distribution with this hash as a version + fixed timestamp -> dogfood-first

A "build session" represents a single invocation of Gradle, for example when you run `gradlew build`.
A session runs the build one or more times.
For example, when continuous build is enabled, the session may run the build many times, but when it is disabled, the session will run the build once only.

The build session state is managed by the `BuildSessionState` class.

        setupPluginRequirements()
    }

    /**
     * Create projects and files required for plugins applied to the project (including transitively applied plugins).
     * These files are not required to run the task itself, but are required to apply the binary-compatibility plugin.
     */
    protected
    fun setupPluginRequirements() {
        projectDir.resolve("version.txt").writeText("9999999.0") // All released versions should be lower than this

        assertNotNull(expires); // Returns documentExpires when config is null
        assertEquals(currentTime + 1000, expires.getTime());

        // Test when documentExpires is set but config is provided (but config has no timeToLive)
        crawlingInfoHelper.documentExpires = currentTime + 5000;

        // For this test, we'll focus on the documentExpires fallback logic