[RORDEV-1228] Move CI from Azure Pipelines to GitHub Actions (Ubicloud Linux + GitHub-hosted Windows)

[sscarduzio]

This PR moves our CI from Azure Pipelines to GitHub Actions. Linux jobs run on Ubicloud runners (4 CPU / 16 GB). Windows jobs run on GitHub's own windows-2025 machines (free for public repos). Azure triggers are turned off in this same PR, but the Azure pipeline can still be run by hand as a fallback until we delete it.

The build scripts themselves are untouched — every job still calls ci/run-pipeline.sh with a ROR_TASK, exactly like on Azure. Only the orchestration around them was rewritten.

The headline numbers

A full PR run now takes ~55 minutes. On Azure it took 4h48. Cost is about $0.50 per PR run (~$14/month).

	Azure	Now	Why
One Linux test leg	85–100 min (mostly queue)	18–24 min	each leg runs 4 test JVMs in parallel on its own VM
One Windows test leg	~70–78 min	28–40 min	3 parallel test JVMs, antivirus exclusions, faster ES installs
Whole run	4h48	~55 min	every job gets its own fresh VM — no shared queue

What's in the PR

• .github/workflows/ci.yml — all 14 Azure stages as GitHub jobs. Test matrices are computed per trigger: full 34 Linux / 33 Windows versions on develop/master, a 10 / 3 subset on PRs. Skipped versions never start a VM.
• Test parallelism (new, Azure ran everything serially):
  • Each Linux leg splits its suites across 4 JVMs, packed by measured duration so no JVM becomes the long pole (integration-tests/suite-timings.json).
  • A machine-wide gate (HeavySuiteGate) limits how many multi-node-cluster suites can boot at the same time. Without it, 16 GB machines run out of memory — we measured this, repeatedly.
  • Windows got the same treatment: 3 JVMs with separate port ranges and install dirs, since ES runs as native processes there (no Docker).
• Leaner test ES nodes: features no test ever uses are disabled per version — ML, watcher, built-in index templates, APM templates, and similar. Less memory, faster boots.
• Fixes found along the way: a secret that would have been printed to public logs by ci/docker-hub-auth.sh, a WireMock port clash between parallel Windows JVMs, an ILM test race, and a too-short wait in the audit tests.
• Docs: ci/github/PORT.md (how the port maps to Azure, and how the parallelism works), ci/github/SECRETS.md (all 17 secrets + 8 variables to set, with a helper script).

The current settings (4 JVMs, gate of 2, balanced packing) are the measured sweet spot for this machine size. We tried going further — 5 JVMs, gate of 3, smaller heaps, deleting unused ES modules from the image — each on an isolated one-leg test run. Every one of them hit a wall (out of memory, boot timeouts, or an ES-internal module dependency), so this is where the knobs stay.

Validation

The full matrix (10 Linux + 3 Windows legs) ran green end to end, including the release-path job conditions (checked against a written scenario table for every trigger type). Two independent review passes over the whole diff found no correctness issues.

Azure → GitHub Actions mapping (reviewer reference — the current-state architecture lives in ci/README.md)

Azure stage	GH job	Notes
SUPERSEDE_GUARD	—	replaced by native concurrency (cancel-in-progress for PRs only; branch pushes queue, so a release run is never cancelled)
DISK_PROBE	disk_probe	manual run_disk_probe
ES_S3_UP	es_s3_up	newes/* branches; ordered before all check/test jobs
BUILD_TOOLCHAINS_IMAGE	build_toolchains_image	weekly cron + manual
TOOLCHAINS_VERIFY	toolchains_verify
OPTIONAL_CHECKS (CVE)	cve_check	continue-on-error; monthly cache key
REQUIRED_CHECKS	required_checks	4-way matrix
TEST (unit)	unit_tests
TEST (Linux IT ×3 jobs)	it_linux	one dynamic matrix (full 34 / PR 10)
TEST (Windows IT ×3 jobs)	it_windows	one dynamic matrix (33 / 7 / 3)
TEST (Windows unit)	unit_tests_windows	manual
BUILD_ROR	build_ror	PR only; gates on Linux and Windows
DETERMINE_CI_TYPE → UPLOAD_PRE_ROR / RELEASE_ROR / PUBLISH_MVN	same names	!cancelled() + explicit needs.<job>.result (GH skips dependents of skipped jobs — this keeps release_without_testing working)

All 5 Azure manual actions are ported: run_all_tests_on_linux, run_all_tests_on_windows, build_toolchains_image, release_without_testing, run_disk_probe.

Azure-feature translations: $(System.AccessToken) → GITHUB_TOKEN; ##vso[task.setvariable] → $GITHUB_OUTPUT; secure file secret.pgp → base64 secret decoded in-step; Cache@2 monthly CVE key → actions/cache + date +%Y%m; tag push via permissions: contents: write (no SSH deploy key).

Deliberately different from Azure: markdown-only changes anywhere skip CI (Azure's globs couldn't express that); the docker pre-clean/reap steps are dropped (runners are ephemeral VMs).

Before merging

1. Set the repo secrets/variables (ci/github/set-secrets.sh, values map 1:1 from the Azure variable group).
2. Add an NVD API key to make cve_check green (it's the only red job).
3. After merge, keep Azure as a manual fallback for one release cycle, then delete it.

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features
  • Added a GitHub Actions-based CI pipeline with sharded Linux/Windows integration testing, release/publish gating, auditing, and artifact reporting.
  • Introduced deterministic suite sharding utilities, suite timing support, and optional “heavy suite” concurrency gating.
• Bug Fixes
  • Improved integration-test resilience with async polling/retries for ILM step changes, settings reloads, audit sink recovery, and container startup.
  • Reduced cross-shard interference via Windows port/directory sharding, reused templates/ES unpacking, and better toolchain/worker reuse.
• Documentation
  • Added a migration guide covering workflow behavior, trigger mappings, and first-run checklist.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

The pull request ports CI orchestration from Azure Pipelines to GitHub Actions, including matrix-based Linux and Windows testing, validation, release, and publishing jobs. Integration tests gain deterministic hash or timing-based sharding, shard-specific outputs, cross-process locking, heavy-suite gating, and Windows resource isolation. Test infrastructure adds Elasticsearch configuration defaults and startup retry handling, while several asynchronous tests replace fixed waits with polling.

Estimated code review effort: 5 (Critical) | ~120 minutes

Sequence Diagram(s)

sequenceDiagram
  participant GitHubActions
  participant setup
  participant required_checks
  participant it_linux
  participant it_windows
  participant determine_ci_type
  participant release_ror
  GitHubActions->>setup: compute execution flags and test matrices
  setup->>required_checks: run repository validation
  setup->>it_linux: start Linux integration shards
  setup->>it_windows: start Windows integration shards
  required_checks->>determine_ci_type: provide validation results
  it_linux->>determine_ci_type: provide Linux test result
  it_windows->>determine_ci_type: provide Windows test result
  determine_ci_type->>release_ror: select release or test flow

Loading

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: migrating CI from Azure Pipelines to GitHub Actions with the new Linux and Windows runner setup.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/ubicloud-ci-port

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 3

🧹 Nitpick comments (4)

integration-tests/src/test/scala/tech/beshu/ror/integration/suites/IndexLifecycleManagementApiSuite.scala (1)

117-201: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Extract shared ILM step JSON payloads to reduce triplication.

The currentStep and nextStep JSON bodies are byte-for-byte identical across all three eventually blocks (and also appear in the unchanged "be forbidden" test at lines 206-223). Defining them once as class-level vals would eliminate ~30 lines of duplication and make step-format changes a single-point edit.

♻️ Proposed extraction

   private lazy val adminIndexManager = new IndexManager(adminClient, esVersionUsed)
   private lazy val adminIndexLifecycleManager = new IndexLifecycleManager(adminClient, esVersionUsed)
   private lazy val dev1IndexLifecycleManager = new IndexLifecycleManager(basicAuthClient("dev1", "test"), esVersionUsed)
   private lazy val dev3IndexLifecycleManager = new IndexLifecycleManager(basicAuthClient("dev3", "test"), esVersionUsed)

+  private val newCompleteStep = ujson.read(
+    s"""
+       |{
+       |  "phase": "new",
+       |  "action": "complete",
+       |  "name": "complete"
+       |}
+       """.stripMargin
+  )
+  private val warmForcemergeStep = ujson.read(
+    s"""
+       |{
+       |  "phase": "warm",
+       |  "action": "forcemerge",
+       |  "name": "forcemerge"
+       |}
+       """.stripMargin
+  )
+
   override implicit val patienceConfig: PatienceConfig =
     PatienceConfig(timeout = scaled(Span(30, Seconds)), interval = scaled(Span(200, Millis)))

Then each eventually block simplifies to:

           eventually {
             val result = dev3IndexLifecycleManager.moveToLifecycleStep(
               index,
-              currentStep = ujson.read(s"""
-                                          |{
-                                          |  "phase": "new",
-                                          |  "action": "complete",
-                                          |  "name": "complete"
-                                          |}
-               """.stripMargin),
-              nextStep = ujson.read(
-                s"""
-                   |{
-                   |  "phase": "warm",
-                   |  "action": "forcemerge",
-                   |  "name": "forcemerge"
-                   |}
-               """.stripMargin
-              )
+              currentStep = newCompleteStep,
+              nextStep = warmForcemergeStep
             )
             result should have statusCode 200
           }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@integration-tests/src/test/scala/tech/beshu/ror/integration/suites/IndexLifecycleManagementApiSuite.scala`
around lines 117 - 201, Extract the identical ILM step JSON payloads used by the
three `eventually` blocks and the unchanged “be forbidden” test into class-level
vals. Update each `moveToLifecycleStep` call, including `currentStep` and
`nextStep`, to reuse those shared values while preserving the existing payload
contents and test behavior.

.github/workflows/ci.yml (1)

305-320: 🔒 Security & Privacy | 🔵 Trivial

Fork PRs execute on Ubicloud (self-hosted-style) runners.

it_linux (and build_ror) run on ubicloud-standard-4 for every pull_request event, including from public forks, since their if conditions don't exclude fork-origin PRs. GitHub secrets are safely withheld from forks, but arbitrary PR-supplied code still executes on these non-GitHub-hosted VMs. The comments elsewhere in this file claim Ubicloud VMs are "ephemeral" (Line 71-72), which would mitigate persistence/lateral-movement risk similarly to GitHub-hosted runners — worth confirming that guarantee holds, and that fork-PR-run approval gating (Require approval for first-time contributors or similar) is enabled at the repo level.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/ci.yml around lines 305 - 320, Prevent untrusted fork pull
requests from executing on Ubicloud runners: update the it_linux and build_ror
job conditions or runner selection so fork-origin PRs use GitHub-hosted runners
or are skipped. Apply the same protection consistently to both jobs, and confirm
repository approval gating is enabled for first-time fork contributors.

build-base/src/main/java/tech/beshu/ror/buildbase/ParallelProcessRunner.java (1)

93-95: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Generic runner hardcodes a project-specific env var.

ParallelProcessRunner is a generic parallel-process utility, but it unconditionally injects a Gradle/ROR-specific env var (ROR_REUSE_ASSEMBLED) into every command it runs. Harmless today since ShardedGradlewTest is the only caller, but it couples orchestration policy into a reusable primitive. Consider accepting this as a per-command (or per-runner) option instead of hardcoding it.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@build-base/src/main/java/tech/beshu/ror/buildbase/ParallelProcessRunner.java`
around lines 93 - 95, Remove the hardcoded ROR_REUSE_ASSEMBLED environment
injection from ParallelProcessRunner and expose environment customization as a
per-command or per-runner option. Update ShardedGradlewTest or its caller to
supply this variable explicitly, while keeping ParallelProcessRunner generic for
other processes.

tests-utils/src/main/scala/tech/beshu/ror/utils/containers/windows/WindowsEsDirectoryManager.scala (1)

169-238: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

LGTM on the template lock/marker approach itself.

The ensureTemplate double-checked file-lock pattern is correct and well-commented. One small, optional improvement: the robocopy result is discarded after reading .exitCode — on failure (rc >= 8) the exception only reports the code, not robocopy's own diagnostic output, which was piped and thrown away. Capturing stdout/stderr in the exception message would speed up triage of Windows CI robocopy failures.

🩹 Optional: surface robocopy output on failure

-    val rc = os
+    val result = os
       .proc("robocopy", template.toString, targetDir.toString, "/E", "/MT:16", "/NFL", "/NDL", "/NJH", "/NJS", "/NP")
       .call(check = false, stdout = os.Pipe, stderr = os.Pipe)
-      .exitCode
-    if (rc >= 8) throw new IllegalStateException(s"robocopy of ES template failed with exit code $rc")
+    if (result.exitCode >= 8)
+      throw new IllegalStateException(
+        s"robocopy of ES template failed with exit code ${result.exitCode}: ${result.out.text()} ${result.err.text()}"
+      )

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@tests-utils/src/main/scala/tech/beshu/ror/utils/containers/windows/WindowsEsDirectoryManager.scala`
around lines 169 - 238, Update unzipEs’s robocopy invocation to retain the
process result, including its piped stdout and stderr, instead of only
extracting exitCode. When rc >= 8, include the captured diagnostic output in the
IllegalStateException while preserving the existing success handling for exit
codes 0–7.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/ci.yml:
- Around line 138-139: Update every listed actions/checkout@v4 step in the
workflow, including the checkout near line 138 and the additional referenced
steps, to set persist-credentials: false in their with configuration. Preserve
the existing release_ror checkout setting of persist-credentials: true because
that job pushes a tag.

In `@ci/github/set-secrets.sh`:
- Around line 10-11: Update set_secret and set_var to distinguish blank inputs
from failed gh commands: explicitly check whether the value is empty and print
the existing skip message only in that case; otherwise invoke gh secret set or
gh variable set and preserve its nonzero failure status instead of routing
failures to the skip branch.

In
`@tests-utils/src/main/scala/tech/beshu/ror/utils/containers/HeavySuiteGate.scala`:
- Around line 69-81: Update the slot acquisition logic in HeavySuiteGate so
FileChannel is always closed when tryLock() throws, while preserving the
existing behavior for successful acquisition and null-lock cases. Use a
try/finally or equivalent guarded cleanup around channel.tryLock(), keeping the
channel open only when a lock is successfully stored in acquired.

---

Nitpick comments:
In @.github/workflows/ci.yml:
- Around line 305-320: Prevent untrusted fork pull requests from executing on
Ubicloud runners: update the it_linux and build_ror job conditions or runner
selection so fork-origin PRs use GitHub-hosted runners or are skipped. Apply the
same protection consistently to both jobs, and confirm repository approval
gating is enabled for first-time fork contributors.

In
`@build-base/src/main/java/tech/beshu/ror/buildbase/ParallelProcessRunner.java`:
- Around line 93-95: Remove the hardcoded ROR_REUSE_ASSEMBLED environment
injection from ParallelProcessRunner and expose environment customization as a
per-command or per-runner option. Update ShardedGradlewTest or its caller to
supply this variable explicitly, while keeping ParallelProcessRunner generic for
other processes.

In
`@integration-tests/src/test/scala/tech/beshu/ror/integration/suites/IndexLifecycleManagementApiSuite.scala`:
- Around line 117-201: Extract the identical ILM step JSON payloads used by the
three `eventually` blocks and the unchanged “be forbidden” test into class-level
vals. Update each `moveToLifecycleStep` call, including `currentStep` and
`nextStep`, to reuse those shared values while preserving the existing payload
contents and test behavior.

In
`@tests-utils/src/main/scala/tech/beshu/ror/utils/containers/windows/WindowsEsDirectoryManager.scala`:
- Around line 169-238: Update unzipEs’s robocopy invocation to retain the
process result, including its piped stdout and stderr, instead of only
extracting exitCode. When rc >= 8, include the captured diagnostic output in the
IllegalStateException while preserving the existing success handling for exit
codes 0–7.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 82ffa427-8a22-42eb-b586-5ecbd6a23d5b

📥 Commits

Reviewing files that changed from the base of the PR and between 93fd0db and 1234cb1.

📒 Files selected for processing (23)

• .github/actionlint.yaml
• .github/workflows/ci.yml
• azure-pipelines.yml
• build-base/src/main/java/tech/beshu/ror/buildbase/ParallelProcessRunner.java
• build-base/src/main/java/tech/beshu/ror/buildbase/ShardedGradlewTest.java
• ci/ci-lib.sh
• ci/docker-hub-auth.sh
• ci/github/PORT.md
• ci/github/SECRETS.md
• ci/github/set-secrets.sh
• integration-tests/build.gradle
• integration-tests/src/test/scala/tech/beshu/ror/integration/suites/IndexLifecycleManagementApiSuite.scala
• integration-tests/src/test/scala/tech/beshu/ror/integration/suites/base/BaseAdminApiSuite.scala
• integration-tests/src/test/scala/tech/beshu/ror/integration/suites/base/BaseAuditingToolsSuite.scala
• integration-tests/src/test/scala/tech/beshu/ror/integration/suites/base/support.scala
• integration-tests/suite-timings.json
• tests-utils/src/main/scala/tech/beshu/ror/utils/containers/HeavySuiteGate.scala
• tests-utils/src/main/scala/tech/beshu/ror/utils/containers/Wiremock.scala
• tests-utils/src/main/scala/tech/beshu/ror/utils/containers/images/Elasticsearch.scala
• tests-utils/src/main/scala/tech/beshu/ror/utils/containers/images/XpackSecurityPlugin.scala
• tests-utils/src/main/scala/tech/beshu/ror/utils/containers/windows/WindowsEsDirectoryManager.scala
• tests-utils/src/main/scala/tech/beshu/ror/utils/containers/windows/WindowsEsPortProvider.scala
• tests-utils/src/main/scala/tech/beshu/ror/utils/gradle/RorPluginGradleProject.scala

[coderabbitai]

🧹 Nitpick comments (1)

tests-utils/src/main/scala/tech/beshu/ror/utils/containers/EsContainer.scala (1)

157-174: 🩺 Stability & Availability | 🔵 Trivial | 💤 Low value

Retry logic is well-structured; one consideration on Thread.sleep interrupt handling.

The one-time delayed retry for the Docker classic-builder race is clean and well-documented. Thread.sleep(5000) can throw InterruptedException, which would propagate as an unchecked exception and bypass the error logging at line 168. Since start() already throws on failure and the caller wraps this in Task.delay(...).runSyncUnsafe(...), this is low-risk in practice. However, catching InterruptedException explicitly and either restoring the interrupt flag or falling through to the retry would make the behavior more robust.

Optional: handle InterruptedException during sleep

       case ex: Throwable if isDockerParentImageRace(ex) =>
         logger.warn("Docker parent-image build race detected - retrying container start once", ex)
-        Thread.sleep(5000)
+        try Thread.sleep(5000)
+        catch { case _: InterruptedException => Thread.currentThread().interrupt() }
         try {

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests-utils/src/main/scala/tech/beshu/ror/utils/containers/EsContainer.scala`
around lines 157 - 174, Update the retry branch in the container start flow
around isDockerParentImageRace and Thread.sleep(5000) to handle
InterruptedException explicitly. Restore the thread’s interrupt status and route
the interruption through the existing retry-failure logging/error path,
preserving the one-time retry behavior and avoiding an unlogged escape.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In
`@tests-utils/src/main/scala/tech/beshu/ror/utils/containers/EsContainer.scala`:
- Around line 157-174: Update the retry branch in the container start flow
around isDockerParentImageRace and Thread.sleep(5000) to handle
InterruptedException explicitly. Restore the thread’s interrupt status and route
the interruption through the existing retry-failure logging/error path,
preserving the one-time retry behavior and avoiding an unlogged escape.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 7f1ec164-b9f0-4c8a-8153-3214de3a7ebf

📥 Commits

Reviewing files that changed from the base of the PR and between 1234cb1 and fdc70f6.

📒 Files selected for processing (1)

• tests-utils/src/main/scala/tech/beshu/ror/utils/containers/EsContainer.scala

[coderabbitai]

🧹 Nitpick comments (1)

tests-utils/src/main/scala/tech/beshu/ror/utils/misc/FileLockSemaphore.scala (1)

41-60: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win

Consider adding a configurable timeout to acquire.

The current implementation blocks indefinitely. While the Javadoc notes self-healing on process death, a holder that hangs without crashing (deadlock, infinite loop) will never release its slot, causing all waiting shards to block until the CI job timeout — a silent hang with no diagnostic output. A configurable max-wait with a clear error message would fail fast and speed up diagnosis.

♻️ Optional timeout parameter

- /** Blocks until a slot is free. `label` is only a log tag. */
- def acquire(label: String): Slot = {
+ /** Blocks until a slot is free, or `timeoutMillis` elapses. `label` is only a log tag. */
+ def acquire(label: String, timeoutMillis: Long = Long.MaxValue): Slot = {
    val start = System.currentTimeMillis()

    `@tailrec`
    def loop(attempt: Int): Slot = {
+     if (System.currentTimeMillis() - start > timeoutMillis) {
+       throw new TimeoutException(s"[$label] timed out after ${elapsedSeconds(start)}s waiting for a free slot")
+     }
      tryAcquireAnySlot() match {
        case Some(slot) =>
          logger.info(s"[$label] slot acquired after ${elapsedSeconds(start)}s")
          slot
        case scala.None =>
          if (attempt % 20 == 0) {
            logger.info(s"[$label] still waiting for a free slot (${elapsedSeconds(start)}s)")
          }
          Thread.sleep(3000)
          loop(attempt + 1)
      }
    }

    loop(attempt = 1)
  }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests-utils/src/main/scala/tech/beshu/ror/utils/misc/FileLockSemaphore.scala`
around lines 41 - 60, Update FileLockSemaphore.acquire to support a configurable
maximum wait duration while retrying in its nested loop. Track elapsed time and,
once the limit is reached, fail with a clear diagnostic message identifying the
label and timeout instead of sleeping and recursing indefinitely; preserve the
existing slot-acquisition and periodic waiting behavior before the timeout.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In
`@tests-utils/src/main/scala/tech/beshu/ror/utils/misc/FileLockSemaphore.scala`:
- Around line 41-60: Update FileLockSemaphore.acquire to support a configurable
maximum wait duration while retrying in its nested loop. Track elapsed time and,
once the limit is reached, fail with a clear diagnostic message identifying the
label and timeout instead of sleeping and recursing indefinitely; preserve the
existing slot-acquisition and periodic waiting behavior before the timeout.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 848e87d9-2e52-48ae-8992-ff508b243b1a

📥 Commits

Reviewing files that changed from the base of the PR and between fb290ce and 80e056f.

📒 Files selected for processing (15)

• .github/workflows/ci.yml
• build-base/src/main/java/tech/beshu/ror/buildbase/SuiteSharder.java
• build-base/src/test/java/tech/beshu/ror/buildbase/SuiteSharderTest.java
• ci/github/PORT.md
• integration-tests/build.gradle
• integration-tests/src/test/scala/tech/beshu/ror/integration/suites/base/BaseAuditingToolsSuite.scala
• integration-tests/src/test/scala/tech/beshu/ror/integration/suites/base/support.scala
• integration-tests/suite-timings.json
• tests-utils/src/main/scala/tech/beshu/ror/utils/containers/EsContainer.scala
• tests-utils/src/main/scala/tech/beshu/ror/utils/containers/Wiremock.scala
• tests-utils/src/main/scala/tech/beshu/ror/utils/containers/images/XpackSecurityPlugin.scala
• tests-utils/src/main/scala/tech/beshu/ror/utils/containers/windows/WindowsEsDirectoryManager.scala
• tests-utils/src/main/scala/tech/beshu/ror/utils/containers/windows/WindowsEsPortProvider.scala
• tests-utils/src/main/scala/tech/beshu/ror/utils/misc/FileLockSemaphore.scala
• tests-utils/src/main/scala/tech/beshu/ror/utils/misc/RorShard.scala

💤 Files with no reviewable changes (1)

• tests-utils/src/main/scala/tech/beshu/ror/utils/containers/images/XpackSecurityPlugin.scala

🚧 Files skipped from review as they are similar to previous changes (10)

• tests-utils/src/main/scala/tech/beshu/ror/utils/containers/windows/WindowsEsPortProvider.scala
• integration-tests/suite-timings.json
• tests-utils/src/main/scala/tech/beshu/ror/utils/containers/EsContainer.scala
• tests-utils/src/main/scala/tech/beshu/ror/utils/containers/Wiremock.scala
• integration-tests/build.gradle
• integration-tests/src/test/scala/tech/beshu/ror/integration/suites/base/support.scala
• ci/github/PORT.md
• tests-utils/src/main/scala/tech/beshu/ror/utils/containers/windows/WindowsEsDirectoryManager.scala
• integration-tests/src/test/scala/tech/beshu/ror/integration/suites/base/BaseAuditingToolsSuite.scala
• .github/workflows/ci.yml