LCORE-489: log unsuccessful docker start

[radofuchs]

Description

log unsuccessful docker start

Type of change

• Refactor
• New feature
• Bug fix
• CVE fix
• Optimization
• Documentation Update
• Configuration Update
• Bump-up service version
• Bump-up dependent library
• Bump-up library or tool used for development (does not change the final image)
• CI configuration change
• Konflux configuration change
• Unit tests improvement
• Integration tests improvement
• [] End to end tests improvement

Related Tickets & Documents

• Related Issue #LCORE-489
• Closes #

Checklist before requesting a review

• I have performed a self-review of my code.
• PR has passed all pre-merge test jobs.
• If it is a core feature, I have added thorough tests.

Testing

• Please provide detailed steps to perform tests related to this code change.
• How were the fix/results from this change verified? Please provide relevant screenshots or results.

Summary by CodeRabbit

• Tests

  • Improved end-to-end test workflow with an immediate post-start health check that fails fast with logs if services don’t start correctly.
  • Removed the fixed wait period, reducing flakiness and speeding up feedback when services are healthy.

• Chores

  • Streamlined CI steps for clearer diagnostics and faster, more reliable test runs.

[coderabbitai]

Walkthrough

Adds an immediate post-start container health check to the e2e GitHub Actions workflow after docker compose up -d, logs and fails on any non-running containers, and removes the prior fixed 20-second wait step.

Changes

Cohort / File(s)	Summary
CI workflow health check adjustment .github/workflows/e2e_tests.yaml	Inserted a post-start check using docker compose ps to detect Exit/exited/stopped and print logs on failure; removed the separate fixed wait step; subsequent steps run only if the check passes.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  participant GH as GitHub Actions
  participant DC as docker compose
  participant SVC as Services

  GH->>DC: up -d
  DC->>SVC: Start containers
  GH->>DC: ps (inspect states)
  alt Any container exited/stopped
    GH->>DC: logs
    GH-->>GH: Fail step (exit 1)
  else All running
    GH-->>GH: "All services started successfully."
    GH->>GH: Proceed to next steps
  end

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Suggested reviewers

• tisnik

Pre-merge checks (3 passed)

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The title succinctly captures the core change of logging failed Docker startup events immediately after container initialization and aligns directly with the updates made to the CI workflow. It is concise and specific enough that a team member reviewing history would understand the primary purpose of the pull request.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

Poem

I thump the ground—containers rise,
No sleepy waits, just quick-bun eyes.
If one hops out, I fetch the logs,
Nose twitching through the misty fogs.
All green? I nibble clover, grin—
CI’s swift, let testing begin! 🐇🚀

Tip

👮 Agentic pre-merge checks are now available in preview!

Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.

• Built-in checks – Quickly apply ready-made checks to enforce title conventions, require pull request descriptions that follow templates, validate linked issues for compliance, and more.
• Custom agentic checks – Define your own rules using CodeRabbit’s advanced agentic capabilities to enforce organization-specific policies and workflows. For example, you can instruct CodeRabbit’s agent to verify that API documentation is updated whenever API schema files are modified in a PR. Note: Upto 5 custom checks are currently allowed during the preview period. Pricing for this feature will be announced in a few weeks.

Please see the documentation for more information.

Example:

reviews:
  pre_merge_checks:
    custom_checks:
      - name: "Undocumented Breaking Changes"
        mode: "warning"
        instructions: |
          Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).

Please share your feedback with us on this Discord post.

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between fdd00e1 and 0d2cd14.

📒 Files selected for processing (1)

• .github/workflows/e2e_tests.yaml (1 hunks)

🧰 Additional context used

🪛 YAMLlint (1.37.1)

.github/workflows/e2e_tests.yaml

[error] 244-244: trailing spaces

(trailing-spaces)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: build-pr
• GitHub Check: e2e_tests

🔇 Additional comments (5)

.github/workflows/e2e_tests.yaml (5)

244-252: Make startup check deterministic; use docker compose up --wait and parse JSON for unhealthy containers.

grep -E 'Exit|exited|stopped' can miss unhealthy states and may false-positive. Prefer Compose’s wait + a JSON check; also limit and decolorize logs, and print only failing services.
[ suggest_essential_refactor ]

Apply:

-          
-          # Check for errors and show logs if any services failed
-          if docker compose ps | grep -E 'Exit|exited|stopped'; then
-            echo "Some services failed to start - showing logs:"
-            docker compose logs
-            exit 1
-          else
-            echo "All services started successfully"
-          fi
+          # Wait for services to reach running/healthy, then double-check state
+          if ! docker compose up -d --wait; then
+            echo "Some services failed to become healthy - showing logs:"
+            docker compose ps
+            docker compose logs --no-color --tail=200
+            exit 1
+          fi
+
+          # Guard: fail if any service is not running or unhealthy
+          if docker compose ps --format json | jq -e 'map(select(.State!="running" or (.Health? and .Health!="healthy"))) | length>0' >/dev/null; then
+            echo "Some services are not running/healthy - showing logs for failing services:"
+            FAILED="$(docker compose ps --format json | jq -r '.[] | select(.State!="running" or (.Health? and .Health!="healthy")) | .Name')"
+            docker compose logs --no-color --tail=200 ${FAILED}
+            exit 1
+          fi
+          echo "All services started successfully."

---

244-244: Fix trailing whitespace (YAML lint error).

Removes trailing spaces to satisfy yamllint.
[ suggest_nitpick ]

-          
+

---

254-258: Replace fixed sleep with an active readiness probe or remove it after --wait.

If you keep --wait, this step is redundant. Otherwise, use a retrying HTTP probe instead of a blind sleep.
[ suggest_optional_refactor ]

-      - name: Wait for services
-        run: |
-          echo "Waiting for services to be healthy..."
-          sleep 20  # adjust depending on boot time
+      - name: Wait for API readiness
+        run: |
+          echo "Waiting for API to be ready..."
+          for i in {1..30}; do
+            if curl -sf http://localhost:8080/v1/models >/dev/null; then
+              echo "API is ready."
+              exit 0
+            fi
+            sleep 2
+          done
+          echo "Timeout waiting for API readiness"
+          docker compose logs --tail=50
+          exit 1

---

239-241: Avoid leaking secret metadata; don’t print API key length.

Printing the length of a secret is unnecessary signal. Drop it.
[ raise_critical_issue ]

-          echo "OPENAI_API_KEY is set: $([ -n "$OPENAI_API_KEY" ] && echo 'YES' || echo 'NO')"
-          echo "OPENAI_API_KEY length: ${#OPENAI_API_KEY}"
+          echo "OPENAI_API_KEY is set: $([ -n "$OPENAI_API_KEY" ] && echo 'YES' || echo 'NO')"

---

4-4: Security: pull_request_target + job-level secrets runs untrusted fork code with secrets.

This workflow checks out and runs PR head code while exposing OPENAI_API_KEY. For forks, switch to pull_request or guard secrets (e.g., conditionally set env only for trusted events) to prevent secret exfiltration.
[ raise_critical_issue ]

Options (pick one):

• Use on: [push, pull_request] and remove secrets on PRs from forks.
• Gate secrets: if: github.event_name == 'push' || github.event.pull_request.head.repo.full_name == github.repository on steps that need them; or move secrets to an environment with required reviewers.
• Keep pull_request_target but run only trusted, base-repo code (checkout github.sha) and invoke PR code via a sandboxed job without secrets.

Also applies to: 10-11

✨ Finishing Touches

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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 and usage tips.}

[tisnik]

LGTM, thank you