Skip to content

Restore NGC workflow for run_cloudxr_via_docker.sh#261

Merged
aristarkhovNV merged 1 commit into
mainfrom
aaristarkhov/ngc-run-via-docker
Mar 13, 2026
Merged

Restore NGC workflow for run_cloudxr_via_docker.sh#261
aristarkhovNV merged 1 commit into
mainfrom
aaristarkhov/ngc-run-via-docker

Conversation

@aristarkhovNV
Copy link
Copy Markdown
Collaborator

@aristarkhovNV aristarkhovNV commented Mar 13, 2026

Summary by CodeRabbit

  • New Features
    • Introduced CloudXR runtime as a containerized service deployable via Docker Compose.
    • Added automatic SDK download to the setup process.
    • Runtime service includes health monitoring and proper environment configuration with graphics, Vulkan, and Python dependencies.
    • OpenXR runtime environment is now pre-configured and ready for deployment.

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Mar 13, 2026

📝 Walkthrough

Walkthrough

Introduces a containerized CloudXR runtime service via Docker, including a multi-stage Dockerfile, Python-based runtime wrapper, initialization entrypoint script, docker-compose orchestration with OpenXR volume mounting, and updated build tooling to handle SDK procurement and service deployment.

Changes

Cohort / File(s) Summary
CloudXR Runtime Docker Infrastructure
deps/cloudxr/Dockerfile.runtime-ngc, deps/cloudxr/docker-compose.yaml
Multi-stage Docker build extracting CloudXR SDK and building runtime image from Ubuntu 24.04 with graphics/Vulkan/Python libraries. docker-compose adds cloudxr-runtime service with NVIDIA runtime, healthcheck, environment configuration, and openxr-volume mount for IPC communication.
CloudXR Runtime Initialization
deps/cloudxr/runtime/entrypoint-ngc.sh, deps/cloudxr/runtime/main.py
Shell entrypoint script prepares /openxr directory, copies runtime artifacts, and delegates to EULA script. Python wrapper loads native libcloudxr.so via ctypes, registers signal handlers, and orchestrates service lifecycle (create → start → join → destroy).
Build Orchestration
scripts/run_cloudxr_via_docker.sh
Updated to download CloudXR Runtime SDK tarball and remove docker-compose.runtime.yaml reference, consolidating to single docker-compose.yaml invocation.

Sequence Diagram(s)

sequenceDiagram
    participant Host as Docker Host
    participant Compose as Docker Compose
    participant Build as Runtime Container
    participant Entrypoint as entrypoint-ngc.sh
    participant Python as main.py
    participant Native as libcloudxr.so

    Host->>Compose: docker-compose up cloudxr-runtime
    Compose->>Build: Build multi-stage image
    Note over Build: Stage 0: Extract SDK<br/>Stage 1: Setup runtime
    Compose->>Build: Start container
    Build->>Entrypoint: Execute entrypoint
    Entrypoint->>Entrypoint: Create /openxr/run<br/>Copy artifacts
    Entrypoint->>Python: Execute main.py
    Python->>Native: ctypes.CDLL(libcloudxr.so)
    Python->>Native: nv_cxr_service_create()
    Python->>Python: Register SIGINT/SIGTERM
    Python->>Native: nv_cxr_service_start()
    Python->>Native: nv_cxr_service_join()
    Note over Python: Awaiting shutdown signal
    Python->>Native: nv_cxr_service_destroy()
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Poem

🐰 A CloudXR runtime hops into view,
Multi-stage Docker with SDK brand new,
Python wraps native with grace so fine,
Volumes and signals in perfect line,
The XR service is ready to shine! ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately describes the main change: restoring NGC workflow support in the run_cloudxr_via_docker.sh script by adding Dockerfile and docker-compose configurations for CloudXR runtime.

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

✨ Finishing Touches
  • 📝 Generate docstrings (stacked PR)
  • 📝 Generate docstrings (commit on current branch)
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch aaristarkhov/ngc-run-via-docker
📝 Coding Plan
  • Generate coding plan for human review comments

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

@aristarkhovNV aristarkhovNV force-pushed the aaristarkhov/ngc-run-via-docker branch from 87371ed to 7b4774f Compare March 13, 2026 21:05
@aristarkhovNV aristarkhovNV force-pushed the aaristarkhov/ngc-run-via-docker branch from 7b4774f to 5fca204 Compare March 13, 2026 21:05
@aristarkhovNV aristarkhovNV marked this pull request as ready for review March 13, 2026 21:10
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 7

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@deps/cloudxr/docker-compose.yaml`:
- Around line 5-29: The cloudxr-runtime service in the docker-compose config is
missing a restart policy so it won't auto-recover if it crashes; update the
cloudxr-runtime service definition (service name: cloudxr-runtime) to include a
restart policy consistent with the other services (e.g., add restart:
unless-stopped) directly under the service's top-level keys so the container
restarts on failure and recovers dependencies like wss-proxy.
- Around line 67-73: Add a clarifying comment to the docker-compose volume
definition for openxr-volume explaining that the host path referenced by
${CXR_HOST_VOLUME_PATH} must be created beforehand by the setup script;
specifically mention the setup_cloudxr_env.sh step (it runs mkdir -p
"$CXR_HOST_VOLUME_PATH") and that run_cloudxr_via_docker.sh sources that script
before docker-compose up so users should run the provided startup flow rather
than launching docker-compose directly.

In `@deps/cloudxr/Dockerfile.runtime-ngc`:
- Around line 30-41: The apt-get install line in the RUN instruction (the block
installing libatomic1, libbsd0, libegl1, libgl1, libglx0, libvulkan1, libx11-6,
libxext6, python3) is unpinned which triggers DL3008 and causes non-reproducible
images; either pin critical packages by specifying explicit versions (use
package=version in the RUN apt-get install invocation after apt-get update) or
add a clear comment above this RUN explaining you intentionally left packages
unpinned for maintenance reasons and documenting that reproducibility is not
required, then update CI/docs accordingly to reflect the chosen strategy.
- Around line 49-50: The Dockerfile RUN line uses chmod 777 on /openxr and
/openxr/run which is overly permissive; change this to more restrictive
permissions (e.g., 755 or 775) and ensure the runtime user can write by setting
ownership to the target UID/GID (use the build/run environment variables
${CXR_UID:-1000} and ${CXR_GID:-1000}) instead of giving world-writable
access—update the RUN command that creates /openxr and /openxr/run to chown
those directories to ${CXR_UID:-1000}:${CXR_GID:-1000} and apply chmod 755 or
775 as appropriate so the non-root container user has the needed access without
777.

In `@deps/cloudxr/runtime/main.py`:
- Around line 7-8: Wrap the libc load and service creation with explicit error
handling: catch exceptions raised by ctypes.CDLL("libcloudxr.so") (the lib
symbol) and raise/log a clearer diagnostic that includes the original exception
and a hint about container library paths; after calling
lib.nv_cxr_service_create(...) check the returned status and the svc
(ctypes.c_void_p instance) for a non-zero/NULL handle, and if creation failed
raise/log a descriptive error and abort further calls that assume a valid svc
handle. Ensure you reference and validate the lib.nv_cxr_service_create call and
the svc variable so subsequent calls never run on an invalid handle.
- Around line 11-12: The stop() handler currently calls
lib.nv_cxr_service_stop(svc) unconditionally; add a state guard like
state["service_created"] before invoking lib.nv_cxr_service_stop to avoid
stopping a non-created or already-destroyed service, and ensure you set
state["service_created"] = True right after successful lib.nv_cxr_service_create
(and clear it when destroying) so stop() checks the same flag before calling
lib.nv_cxr_service_stop(svc).
- Around line 15-20: The native calls nv_cxr_service_create,
nv_cxr_service_start, nv_cxr_service_join, and nv_cxr_service_destroy currently
ignore return values; update the code to capture each call's return code and
validate it (e.g., rc = lib.nv_cxr_service_create(ctypes.byref(svc))) then on
non-success log an error including the return code and perform appropriate error
handling (raise an exception or exit/cleanup the svc) to avoid proceeding after
a failed create/start/join/destroy; ensure svc is only used or destroyed if
create succeeded and that all failures produce clear logs mentioning the
function name (nv_cxr_service_create/start/join/destroy) and the rc.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 4de4e169-1893-4386-849f-28c4a489cf46

📥 Commits

Reviewing files that changed from the base of the PR and between 3e467d8 and 5fca204.

📒 Files selected for processing (5)
  • deps/cloudxr/Dockerfile.runtime-ngc
  • deps/cloudxr/docker-compose.yaml
  • deps/cloudxr/runtime/entrypoint-ngc.sh
  • deps/cloudxr/runtime/main.py
  • scripts/run_cloudxr_via_docker.sh

Comment thread deps/cloudxr/docker-compose.yaml
Comment thread deps/cloudxr/docker-compose.yaml
Comment thread deps/cloudxr/Dockerfile.runtime-ngc
Comment thread deps/cloudxr/Dockerfile.runtime-ngc
Comment thread deps/cloudxr/runtime/main.py
Comment thread deps/cloudxr/runtime/main.py
Comment thread deps/cloudxr/runtime/main.py
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Restores the CloudXR “NGC runtime SDK + Docker” workflow for run_cloudxr_via_docker.sh by switching the dev compose setup to build/run a minimal runtime image directly from the downloaded CloudXR Runtime SDK.

Changes:

  • Add runtime SDK download step to the Docker launch script.
  • Move the CloudXR runtime service definition into deps/cloudxr/docker-compose.yaml (no longer requiring docker-compose.runtime.yaml for this workflow).
  • Introduce an NGC-focused runtime image (Dockerfile.runtime-ngc) and entrypoint + minimal Python runtime launcher.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file
File Description
scripts/run_cloudxr_via_docker.sh Ensures runtime SDK is present before composing services.
deps/cloudxr/runtime/main.py Adds a minimal ctypes-based CloudXR runtime launcher.
deps/cloudxr/runtime/entrypoint-ngc.sh Prepares /openxr runtime artifacts and gates startup on EULA acceptance.
deps/cloudxr/docker-compose.yaml Adds cloudxr-runtime service and shared bind-mounted volume configuration.
deps/cloudxr/Dockerfile.runtime-ngc Builds a minimal runtime image from the downloaded SDK tarball.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

Comment thread deps/cloudxr/runtime/main.py
Comment thread deps/cloudxr/docker-compose.yaml
@aristarkhovNV aristarkhovNV merged commit 4ca7c71 into main Mar 13, 2026
37 checks passed
@aristarkhovNV aristarkhovNV deleted the aaristarkhov/ngc-run-via-docker branch March 13, 2026 21:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants