Parallelize KIND cluster setup with HolmesGPT environment - #1687
Conversation
- Add pip/poetry dependency caching to reduce Python install time - Run KIND cluster setup in background, parallel with Holmes env setup (saves ~70s by overlapping the two independent setup phases) - Install kube-prometheus-stack and metrics-server in parallel within KIND setup (saves ~26s) - Reduce Calico CNI wait loop intervals from 5s to 2s - Remove unnecessary test pod verification step from cluster readiness - Scale pytest parallelism dynamically based on test count (6-20 workers) https://claude.ai/code/session_01ReC3SkRaWTNe3BZyuhLRyx Signed-off-by: Claude <noreply@anthropic.com>
📂 Previous Runs📜 Run @ 586b55d (#22806196276)✅ Results of HolmesGPT evalsAutomatically triggered by commit 586b55d on branch Results of HolmesGPT evals
Benchmark Comparison DetailsBaseline: latest ci-benchmark experiment on master Status: Success - 61 test/model combinations loaded Benchmark experiment:
Time comparison (seconds):
Benchmark has no cost, total tokens, cached tokens data. Will appear after the next weekly benchmark run. Comparison indicators:
📜 Run @ b28cc18 (#22806170809)✅ Results of HolmesGPT evalsAutomatically triggered by commit b28cc18 on branch Results of HolmesGPT evals
Benchmark Comparison DetailsBaseline: latest ci-benchmark experiment on master Status: Success - 61 test/model combinations loaded Benchmark experiment:
Time comparison (seconds):
Benchmark has no cost, total tokens, cached tokens data. Will appear after the next weekly benchmark run. Comparison indicators:
📜 Run @ 37d23da (#22805896168)✅ Results of HolmesGPT evalsAutomatically triggered by commit 37d23da on branch Results of HolmesGPT evals
Benchmark Comparison DetailsBaseline: latest ci-benchmark experiment on master Status: Success - 61 test/model combinations loaded Benchmark experiment:
Time comparison (seconds):
Benchmark has no cost, total tokens, cached tokens data. Will appear after the next weekly benchmark run. Comparison indicators:
📜 Run @ 8f7ea3f (#22795410737)✅ Results of HolmesGPT evalsAutomatically triggered by commit 8f7ea3f on branch Results of HolmesGPT evals
📜 Run @ 59bd1bf (#22764384077)✅ Results of HolmesGPT evalsAutomatically triggered by commit 59bd1bf on branch Results of HolmesGPT evals
✅ Results of HolmesGPT evalsAutomatically triggered by commit 613a3fe on branch Results of HolmesGPT evals
Benchmark comparison unavailable: No ci-benchmark experiments found Benchmark Comparison DetailsBaseline: latest ci-benchmark experiment on master Status: No ci-benchmark experiments found Comparison indicators:
📖 Legend
🔄 Re-run evals manually
Option 1: Comment on this PR with Or with more options (one per line): Run evals on a different branch (e.g., master) for comparison:
Quick re-run: Use Option 2: Trigger via GitHub Actions UI → "Run workflow" Option 3: Add PR labels to include extra evals in automatic regression runs:
Examples: 🏷️ Valid tags
Commands: CLI: |
|
✅ Docker images ready for
Use these tags to pull the images for testing. 📋 Copy commandsgcloud auth configure-docker us-central1-docker.pkg.dev
docker pull us-central1-docker.pkg.dev/robusta-development/temporary-builds/holmes:38d334dd
docker tag us-central1-docker.pkg.dev/robusta-development/temporary-builds/holmes:38d334dd me-west1-docker.pkg.dev/robusta-development/development/holmes-dev:38d334dd
docker push me-west1-docker.pkg.dev/robusta-development/development/holmes-dev:38d334dd
docker pull us-central1-docker.pkg.dev/robusta-development/temporary-builds/holmes-operator:38d334dd
docker tag us-central1-docker.pkg.dev/robusta-development/temporary-builds/holmes-operator:38d334dd me-west1-docker.pkg.dev/robusta-development/development/holmes-operator-dev:38d334dd
docker push me-west1-docker.pkg.dev/robusta-development/development/holmes-operator-dev:38d334ddPatch Helm values in one line (choose the chart you use): HolmesGPT chart: helm upgrade --install holmesgpt ./helm/holmes \
--set registry=me-west1-docker.pkg.dev/robusta-development/development \
--set image=holmes-dev:38d334dd \
--set operator.registry=me-west1-docker.pkg.dev/robusta-development/development \
--set operator.image=holmes-operator-dev:38d334ddRobusta wrapper chart: helm upgrade --install robusta robusta/robusta \
--reuse-values \
--set holmes.registry=me-west1-docker.pkg.dev/robusta-development/development \
--set holmes.image=holmes-dev:38d334dd \
--set holmes.operator.registry=me-west1-docker.pkg.dev/robusta-development/development \
--set holmes.operator.image=holmes-operator-dev:38d334dd |
✅ Deploy Preview for holmes-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
https://claude.ai/code/session_01ReC3SkRaWTNe3BZyuhLRyx Signed-off-by: Claude <noreply@anthropic.com>
https://claude.ai/code/session_01ReC3SkRaWTNe3BZyuhLRyx Signed-off-by: Claude <noreply@anthropic.com>
|
Note Reviews pausedIt 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 Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughInstalls Poetry via a curl installer and caches an in-project Changes
Sequence Diagram(s)sequenceDiagram
participant GH as "GitHub Actions Runner"
participant SetupAction as "setup-holmes-env Action"
participant Cache as "actions/cache"
participant BGScript as "Background KIND setup script"
participant WaitStep as "Wait for KIND setup"
participant TestRunner as "pytest (-n20)"
participant KIND as "KIND Cluster"
GH->>SetupAction: run environment setup
SetupAction->>SetupAction: install Poetry (curl), create .venv, add .venv/bin to PATH
SetupAction->>Cache: restore/save caches (python/.venv, poetry caches)
GH->>BGScript: start KIND setup (background)
BGScript->>KIND: create cluster, load/save node & workload images, apply manifests
BGScript-->>GH: emit KIND_SETUP_COMPLETE sentinel on success
GH->>WaitStep: poll logs for KIND_SETUP_COMPLETE
WaitStep->>KIND: validate cluster status (kubectl)
GH->>TestRunner: run pytest with -n20
TestRunner->>KIND: execute tests
TestRunner-->>GH: upload results/logs
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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. Comment |
https://claude.ai/code/session_01ReC3SkRaWTNe3BZyuhLRyx Signed-off-by: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/actions/setup-holmes-env/action.yml (1)
31-32:⚠️ Potential issue | 🟠 MajorUpdate Poetry to a current stable version; 1.4.0 (early 2023) is severely outdated.
Poetry 1.4.0 is nearly 3 years old. Current stable is 2.3.2 (Feb 2026), with 1.8.5 also available (Dec 2024). The outdated version lacks critical bug fixes and security patches. No compatibility constraint is documented in
pyproject.tomlor elsewhere in the codebase. Update to the latest stable version unless there's a specific compatibility requirement.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/actions/setup-holmes-env/action.yml around lines 31 - 32, The install step pins Poetry to an outdated version (curl ... | python3 - --version 1.4.0); update that install invocation to a current stable release (e.g., replace "--version 1.4.0" with "--version 2.3.2" or use a workflow input/variable like POETRY_VERSION and set it to the latest stable) so the action installs a maintained Poetry release; ensure the change is applied to the install line that runs "curl -sSL https://install.python-poetry.org | python3 - --version ..." in action.yml.
🧹 Nitpick comments (1)
.github/workflows/eval-regression.yaml (1)
687-688: Pin Helm CLI version for reproducible builds.The Helm installation pulls from the
mainbranch without version pinning, which could introduce unexpected breaking changes. Consider using a versioned URL similar to how KIND (v0.31.0) and Calico (v3.31.3) are pinned.♻️ Suggested fix
# Install Helm - curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash + curl https://raw.githubusercontent.com/helm/helm/v3.17.2/scripts/get-helm-3 | DESIRED_VERSION=v3.17.2 bash🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/eval-regression.yaml around lines 687 - 688, Replace the unpinned Helm install curl line that fetches the script from the main branch by pinning to a specific Helm release: set the desired version (e.g., v3.x.y) and use the release-specific URL or the script's VERSION environment variable so the pipeline always installs that tagged Helm release instead of latest; update the line that currently runs "curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash" to reference the chosen tag (or export VERSION=<tag> before running the script) to ensure reproducible builds.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/eval-regression.yaml:
- Line 1007: Replace the hardcoded "-n20" in PYTEST_ARGS with a dynamic worker
count derived from the previously-collected TEST_COUNT: compute a worker count
(for example min(TEST_COUNT, 20) or another cap you prefer) using bash
arithmetic (e.g. compute WORKER_COUNT=$(( TEST_COUNT < 20 ? TEST_COUNT : 20 ))
or similar) and then use "-n${WORKER_COUNT}" when building PYTEST_ARGS; update
the PYTEST_ARGS assignment to reference that computed WORKER_COUNT (keep
EVAL_MARKER_EXPR and existing test list unchanged).
---
Outside diff comments:
In @.github/actions/setup-holmes-env/action.yml:
- Around line 31-32: The install step pins Poetry to an outdated version (curl
... | python3 - --version 1.4.0); update that install invocation to a current
stable release (e.g., replace "--version 1.4.0" with "--version 2.3.2" or use a
workflow input/variable like POETRY_VERSION and set it to the latest stable) so
the action installs a maintained Poetry release; ensure the change is applied to
the install line that runs "curl -sSL https://install.python-poetry.org |
python3 - --version ..." in action.yml.
---
Nitpick comments:
In @.github/workflows/eval-regression.yaml:
- Around line 687-688: Replace the unpinned Helm install curl line that fetches
the script from the main branch by pinning to a specific Helm release: set the
desired version (e.g., v3.x.y) and use the release-specific URL or the script's
VERSION environment variable so the pipeline always installs that tagged Helm
release instead of latest; update the line that currently runs "curl
https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash" to
reference the chosen tag (or export VERSION=<tag> before running the script) to
ensure reproducible builds.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: a68177b9-a020-4ac8-925d-a97592414a72
📒 Files selected for processing (2)
.github/actions/setup-holmes-env/action.yml.github/workflows/eval-regression.yaml
There was a problem hiding this comment.
♻️ Duplicate comments (1)
.github/workflows/eval-regression.yaml (1)
1005-1007:⚠️ Potential issue | 🟡 MinorStill hardcoded at
-n20.
steps.test-preview.outputs.test_countis collected earlier but never used here, so small/manual selections still fan out 20 workers against the same shared test infrastructure. That misses the dynamic scaling described in the PR and keeps the contention risk around the shared port-forward setup.Suggested change
+ TEST_COUNT=${{ steps.test-preview.outputs.test_count }} + CPU_COUNT=$(nproc) + if (( TEST_COUNT == 0 )); then + WORKER_COUNT=1 + else + WORKER_COUNT=$TEST_COUNT + (( WORKER_COUNT < 6 )) && WORKER_COUNT=6 + (( WORKER_COUNT > 20 )) && WORKER_COUNT=20 + (( WORKER_COUNT > CPU_COUNT )) && WORKER_COUNT=$CPU_COUNT + fi - PYTEST_ARGS=(--no-cov tests/llm/test_ask_holmes.py tests/llm/test_investigate.py -s -n20 -m "$EVAL_MARKER_EXPR") + PYTEST_ARGS=(--no-cov tests/llm/test_ask_holmes.py tests/llm/test_investigate.py -s -n"$WORKER_COUNT" -m "$EVAL_MARKER_EXPR")🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/eval-regression.yaml around lines 1005 - 1007, The PYTEST_ARGS variable currently hardcodes "-n20", which ignores the previously collected steps.test-preview.outputs.test_count; update the PYTEST_ARGS construction (the PYTEST_ARGS assignment) to use the dynamic test count output instead of "-n20" by injecting the test_count value from steps.test-preview.outputs.test_count (or an env var fed from that output) so parallel workers scale to the discovered test_count rather than always using 20.
🧹 Nitpick comments (1)
.github/workflows/eval-regression.yaml (1)
605-606: Enablepipefailin the generated KIND setup script.
set -ewill not fail on the left side ofcurl … | bash, so a transient download error can surface later as a much less obvious Helm install failure instead of stopping at the real root cause.Suggested change
- set -e + set -euo pipefailAlso applies to: 688-688
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/eval-regression.yaml around lines 605 - 606, The generated KIND setup script currently uses "#!/bin/bash" followed by "set -e" which doesn't propagate failures through pipelines; update the script to enable pipefail (e.g., replace or augment the "set -e" invocation with a form that enables pipefail, such as adding "set -o pipefail" or using "set -euo pipefail") so that a failed download in a pipeline like "curl … | bash" causes the script to fail immediately; apply the same change to the other occurrence of the script.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In @.github/workflows/eval-regression.yaml:
- Around line 1005-1007: The PYTEST_ARGS variable currently hardcodes "-n20",
which ignores the previously collected steps.test-preview.outputs.test_count;
update the PYTEST_ARGS construction (the PYTEST_ARGS assignment) to use the
dynamic test count output instead of "-n20" by injecting the test_count value
from steps.test-preview.outputs.test_count (or an env var fed from that output)
so parallel workers scale to the discovered test_count rather than always using
20.
---
Nitpick comments:
In @.github/workflows/eval-regression.yaml:
- Around line 605-606: The generated KIND setup script currently uses
"#!/bin/bash" followed by "set -e" which doesn't propagate failures through
pipelines; update the script to enable pipefail (e.g., replace or augment the
"set -e" invocation with a form that enables pipefail, such as adding "set -o
pipefail" or using "set -euo pipefail") so that a failed download in a pipeline
like "curl … | bash" causes the script to fail immediately; apply the same
change to the other occurrence of the script.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: b1c1ebac-f828-4174-bcc0-086a983586f6
📒 Files selected for processing (1)
.github/workflows/eval-regression.yaml
Cache KIND binary, Helm binary, KIND node Docker image, Calico/metrics-server manifests, Helm chart repository data, and all workload container images (Calico, Prometheus, kube-state-metrics, node-exporter, metrics-server). On cache hit: - Binaries loaded from cache instead of downloading (~10s saved) - KIND node image loaded via docker load (~15-20s saved) - Workload images pre-loaded into KIND via kind load image-archive, so pods start without pulling from registries (~40-60s saved) - Helm charts served from local cache (~10s saved) - Manifests read from local files (~5s saved) On cache miss (first run): artifacts are saved for subsequent runs. Cache key includes all component versions to auto-bust on upgrades. https://claude.ai/code/session_01ReC3SkRaWTNe3BZyuhLRyx Signed-off-by: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/eval-regression.yaml (1)
755-788: Parallel background jobs may orphan on partial failure.If the Prometheus install (PROM_PID) fails,
wait $PROM_PIDtriggersset -eand exits the script. However, the metrics-server subshell (METRICS_PID) continues running as an orphaned process, potentially leaving the cluster in an inconsistent state.🛠️ Proposed fix: Add trap to clean up background jobs
+ # Track background PIDs for cleanup + BACKGROUND_PIDS=() + cleanup_background() { + for pid in "${BACKGROUND_PIDS[@]}"; do + kill "$pid" 2>/dev/null || true + done + } + trap cleanup_background EXIT + ( helm repo add prometheus-community https://prometheus-community.github.io/helm-charts # ... rest of prometheus install ) & PROM_PID=$! + BACKGROUND_PIDS+=($PROM_PID) ( kubectl apply -f "$METRICS_MANIFEST" # ... rest of metrics-server install ) & METRICS_PID=$! + BACKGROUND_PIDS+=($METRICS_PID) wait $PROM_PID wait $METRICS_PID + trap - EXIT # Clear trap after successful completion🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/eval-regression.yaml around lines 755 - 788, The two background subshells assigned to PROM_PID and METRICS_PID can be orphaned if one fails; add a cleanup trap before starting them that kills/terminates PROM_PID and METRICS_PID on EXIT or ERR and waits for them to finish, then after launching the subshells use robust waiting and error checking (e.g., capture each wait exit code rather than relying on set -e) so the script explicitly kills the other job if one fails; reference PROM_PID, METRICS_PID, the background subshells (the (...) & blocks), and the wait calls to locate where to add the trap and the explicit kill/wait logic.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/workflows/eval-regression.yaml:
- Around line 755-788: The two background subshells assigned to PROM_PID and
METRICS_PID can be orphaned if one fails; add a cleanup trap before starting
them that kills/terminates PROM_PID and METRICS_PID on EXIT or ERR and waits for
them to finish, then after launching the subshells use robust waiting and error
checking (e.g., capture each wait exit code rather than relying on set -e) so
the script explicitly kills the other job if one fails; reference PROM_PID,
METRICS_PID, the background subshells (the (...) & blocks), and the wait calls
to locate where to add the trap and the explicit kill/wait logic.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 1e2a0a4b-d91a-423e-9540-8eabe7fe0287
📒 Files selected for processing (1)
.github/workflows/eval-regression.yaml
The previous cache only stored ~/.cache/pip and ~/.cache/pypoetry (download caches). With virtualenvs.create=false, poetry install still had to unpack and install every package to system site-packages on every run. Now uses in-project virtualenv (.venv/) and caches it directly. On cache hit, poetry install is near-instant since all packages are already installed. Also adds .venv/bin to PATH so scripts with #!/usr/bin/env python3 work. https://claude.ai/code/session_01ReC3SkRaWTNe3BZyuhLRyx Signed-off-by: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
🧹 Nitpick comments (2)
.github/actions/setup-holmes-env/action.yml (2)
40-44: Consider addingrestore-keysfor partial cache restoration.When
poetry.lockchanges, the exact cache key won't match and there's no fallback. Addingrestore-keysallows restoring a previous virtualenv, andpoetry installwill then only update the diff—often faster than a full install.♻️ Proposed fix to add restore-keys
- name: Cache Python virtualenv uses: actions/cache@v4 with: path: ${{ inputs.working-directory }}/.venv key: venv-${{ inputs.python-version }}-${{ hashFiles(format('{0}/poetry.lock', inputs.working-directory)) }} + restore-keys: | + venv-${{ inputs.python-version }}-🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/actions/setup-holmes-env/action.yml around lines 40 - 44, The cache step "Cache Python virtualenv" (uses: actions/cache@v4) lacks restore-keys, so when the key built from venv-${{ inputs.python-version }}-${{ hashFiles(format('{0}/poetry.lock', inputs.working-directory)) }} misses there is no fallback; add a restore-keys entry (e.g. a prefix fallback like venv-${{ inputs.python-version }}- or venv-) so the action can restore a partial cache and speed up subsequent poetry installs, keeping path: ${{ inputs.working-directory }}/.venv and the existing key intact.
26-38: Consider upgrading Poetry to a more recent stable version for long-term maintenance.Poetry 1.4.0 is available on PyPI but is significantly outdated—the latest stable version is 2.3.2 (as of March 2026). While 1.4.0 remains functional, evaluate whether upgrading to a newer stable release would provide better long-term compatibility and access to recent improvements and security patches.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/actions/setup-holmes-env/action.yml around lines 26 - 38, Update the "Install Poetry" step to install a newer stable Poetry release instead of pinning to 1.4.0: change the install command that pipes to python3 (the curl | python3 - --version 1.4.0 invocation) to use a current stable version (e.g., 2.3.2) or make the version configurable via an environment variable/input so future upgrades are easier; ensure the PATH echo and poetry config virtualenvs.in-project true lines remain unchanged and verify the workflow uses the same binary path ($HOME/.local/bin/poetry) after the change.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/actions/setup-holmes-env/action.yml:
- Around line 40-44: The cache step "Cache Python virtualenv" (uses:
actions/cache@v4) lacks restore-keys, so when the key built from venv-${{
inputs.python-version }}-${{ hashFiles(format('{0}/poetry.lock',
inputs.working-directory)) }} misses there is no fallback; add a restore-keys
entry (e.g. a prefix fallback like venv-${{ inputs.python-version }}- or venv-)
so the action can restore a partial cache and speed up subsequent poetry
installs, keeping path: ${{ inputs.working-directory }}/.venv and the existing
key intact.
- Around line 26-38: Update the "Install Poetry" step to install a newer stable
Poetry release instead of pinning to 1.4.0: change the install command that
pipes to python3 (the curl | python3 - --version 1.4.0 invocation) to use a
current stable version (e.g., 2.3.2) or make the version configurable via an
environment variable/input so future upgrades are easier; ensure the PATH echo
and poetry config virtualenvs.in-project true lines remain unchanged and verify
the workflow uses the same binary path ($HOME/.local/bin/poetry) after the
change.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 775e0410-059d-4559-8f89-42ea84fa8386
📒 Files selected for processing (1)
.github/actions/setup-holmes-env/action.yml
ctr images export fails with "content digest not found" when containerd has multi-arch manifest lists but only the linux/amd64 layers are present. Fix by using --platform linux/amd64 flag, with fallback to per-image export if bulk export still fails. https://claude.ai/code/session_01ReC3SkRaWTNe3BZyuhLRyx Signed-off-by: Claude <noreply@anthropic.com>
…export ctr images export fails on every image in KIND because containerd stores multi-arch manifest lists without all platform layers. Switch to pulling images on the host Docker daemon and using docker save, which produces a tar that kind load image-archive can consume on cache hit. Also make the entire caching block non-fatal (|| true) so image cache failures never break the build. https://claude.ai/code/session_01ReC3SkRaWTNe3BZyuhLRyx Signed-off-by: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/eval-regression.yaml:
- Line 1236: Remove or complete the orphaned trailing comment "# CI speed
optimizations" in the workflow file: either delete that standalone comment line
or replace it with the intended documentation/details about the CI optimization
steps so the meaning is clear; locate the comment by searching for the exact
text "# CI speed optimizations" and update or remove it accordingly.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 10547331-1e65-4086-ae6e-9935451c35d9
📒 Files selected for processing (1)
.github/workflows/eval-regression.yaml
…ression-evals-TfJav
…-TfJav' into claude/speed-up-regression-evals-TfJav
https://claude.ai/code/session_01ReC3SkRaWTNe3BZyuhLRyx Signed-off-by: Claude <noreply@anthropic.com>
…-TfJav' into claude/speed-up-regression-evals-TfJav
Summary
Optimize CI/CD pipeline performance by running KIND cluster setup in parallel with HolmesGPT environment setup, reducing overall workflow execution time by approximately 70 seconds.
Key Changes
Parallel KIND Setup: KIND cluster initialization now runs in the background as a separate shell script (
/tmp/kind-setup.sh) instead of blocking on a dedicated action stepBackground Process Management:
/tmp/kind-setup.log/tmp/kind-setup-pidfor trackingImproved Helm Installations: Prometheus and metrics-server installations now run in parallel within the KIND setup script using background processes (
&) to reduce setup timeDynamic Test Parallelism:
-n10with dynamic-n"$N_WORKERS"calculationEnhanced Setup Action:
setup-holmes-envaction using GitHub Actions cachepoetry.lockhashImplementation Details
waitcommand for parallel Helm installationshttps://claude.ai/code/session_01ReC3SkRaWTNe3BZyuhLRyx
Summary by CodeRabbit