Replace ROS test timeout with a readiness poll

[sgrizan-nv]

Summary by CodeRabbit

• Chores
  • Improved reliability and error reporting in the automated testing infrastructure to provide clearer diagnostics during the build and test process.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: f275471c-c44a-4695-84ba-31b37f3d2d4f

📥 Commits

Reviewing files that changed from the base of the PR and between 18c8e36 and fda65c7.

📒 Files selected for processing (1)

• .github/workflows/build-ubuntu.yml

---

📝 Walkthrough

Walkthrough

Modified the GitHub Actions workflow for test-teleop-ros2 container execution. Replaced synchronous docker run --rm with detached docker run -d using a deterministic container name. Added explicit readiness polling that checks Docker logs for a startup marker (TeleopSession started successfully) with a 30-second timeout and 1-second polling intervals. Implemented differentiated error handling based on container state (running vs exited) at timeout, then collects logs, prints output, and enforces readiness marker observation before proceeding.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

🚥 Pre-merge checks | ✅ 3

✅ 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 'Replace ROS test timeout with a readiness poll' directly and accurately summarizes the main change: replacing a timeout-based approach with explicit readiness polling for container startup.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch sgrizan/branch3

---

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

[jiwenc-nv]

just being paranoid, any chance that two build-ubuntu.yml workflow running together and one will kill the other? can that happen? can we check how long a container is running and only kill if it's long lasting?

[sgrizan-nv]

There is a chance, if the workflows are executed on the same runner. To handle that, we'll need something like #382