ci: Use nvcr.io image for sglang base container

[dillon-cullinan]

Overview:

Using nvidia/cuda:12.9.1-cudnn-devel-ubuntu24.04 is hitting Rate limits in our CI. This PR updates to use nvcr.io/nvidia/cuda:12.9.1-cudnn-devel-ubuntu24.04 which will prevent hitting rate limits since we have an authorized service key. These are the exact same images after validating with docker scout compare.

 ## Overview
  
                      │                    Analyzed Image                    │               Comparison Image                
  ────────────────────┼──────────────────────────────────────────────────────┼───────────────────────────────────────────────
    Target            │  nvcr.io/nvidia/cuda:12.9.1-cudnn-devel-ubuntu24.04  │  nvidia/cuda:12.9.1-cudnn-devel-ubuntu24.04   
      digest          │  b14d354f130f                                        │  b14d354f130f                                 
      tag             │  12.9.1-cudnn-devel-ubuntu24.04                      │  12.9.1-cudnn-devel-ubuntu24.04               
      platform        │ linux/amd64                                          │ linux/amd64                                   
      vulnerabilities │    1C     8H   1277M    37L     5?                   │    1C     8H   1277M    37L     5?            
                      │                                                      │                                               
      size            │ 6.9 GB                                               │ 6.9 GB                                        
      packages        │ 308                                                  │ 308                                           
                      │                                                      │                                               
    Base image        │  ubuntu:24.04                                        │  ubuntu:24.04                                 
      tags            │ also known as                                        │ also known as                                 
                      │   • latest                                           │   • latest                                    
                      │   • noble                                            │   • noble                                     
      vulnerabilities │    0C     0H     6M     6L                           │    0C     0H     6M     6L   

Summary by CodeRabbit

• Chores
  • Enhanced Docker build configuration to support configurable proxy settings for image builds, enabling better flexibility in different network environments.

[coderabbitai]

Walkthrough

Introduces a Docker proxy mechanism by adding a new DOCKER_PROXY build argument. The GitHub Actions workflow passes this argument to the container build process, while the Dockerfile accepts and uses it to prefix the base image URL for framework fetching.

Changes

Cohort / File(s)	Change Summary
Docker Proxy Configuration .github/actions/docker-build/action.yml, container/Dockerfile.sglang	Introduces DOCKER_PROXY build argument to enable proxy-based image fetching. The workflow exposes ECR_HOSTNAME and passes it as a build-arg, while the Dockerfile accepts the argument and applies it as a prefix to the CUDA framework base image.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10–15 minutes

• Verify the DOCKER_PROXY argument is correctly propagated from the GitHub Actions workflow to the Dockerfile
• Confirm the base image URL formatting with the proxy prefix is valid and maintains backward compatibility when DOCKER_PROXY is empty
• Check that existing sccache arguments remain unaffected by the formatting changes

Poem

🐰 A proxy path the rabbit hops today,
Where Docker images find their way,
Through ECR gateways swift and light,
With DOCKER_PROXY shining bright! 📦✨

Pre-merge checks

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.
Description Check	⚠️ Warning	The pull request description provides a clear and informative overview section explaining the problem (Docker rate limits) and the solution (using a proxied image from nvcr.io with authorized service key), supported by docker scout comparison evidence. However, the description is missing several key sections required by the template: the "Details" section lacks specifics about the technical implementation changes, the "Where should the reviewer start?" section provides no guidance on which files to review closely, and the "Related Issues" section is entirely absent with no reference to any associated GitHub issues.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The PR title "ci: Use nvcr.io image for sglang base container" is related to the changeset. The actual changes introduce a DOCKER_PROXY build argument mechanism that allows the sglang base image to be fetched through a proxy (which the PR description indicates is meant to address Docker rate limits by using nvcr.io). The title accurately reflects the intended outcome and primary purpose of the changes, even though the implementation is parameterized rather than hardcoding a specific proxy URL. The title clearly summarizes what the PR aims to accomplish from a user/CI perspective.

---

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.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

container/Dockerfile.sglang (1)

42-43: Add documentation for the DOCKER_PROXY argument.

The DOCKER_PROXY build argument enables pulling the framework base image through a Docker registry proxy to mitigate Docker Hub rate limits. Without clarification, the purpose and expected format (a registry URL with trailing slash, e.g., registry.example.com/dockerhub/) may not be obvious to future maintainers.

Consider adding a brief comment above line 42 explaining the argument's purpose and format:

+# Docker registry proxy to fetch the CUDA framework image (e.g., ECR proxy for Docker Hub rate limiting)
+# If not provided, defaults to empty string and pulls directly from Docker Hub
 ARG DOCKER_PROXY

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between eb3a486 and c2287bb.

📒 Files selected for processing (2)

• .github/actions/docker-build/action.yml (2 hunks)
• container/Dockerfile.sglang (1 hunks)

⏰ 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). (9)

• GitHub Check: trtllm (arm64)
• GitHub Check: sglang (amd64)
• GitHub Check: trtllm (amd64)
• GitHub Check: sglang (arm64)
• GitHub Check: operator (arm64)
• GitHub Check: vllm (arm64)
• GitHub Check: vllm (amd64)
• GitHub Check: operator (amd64)
• GitHub Check: Build and Test - dynamo

🔇 Additional comments (2)

.github/actions/docker-build/action.yml (2)

97-97: Good: ECR_HOSTNAME is properly set as environment variable for build step.

Setting ECR_HOSTNAME as an environment variable (line 97) makes it accessible to the build.sh invocation, enabling the DOCKER_PROXY to be constructed correctly. This follows a clean pattern where the environment variable is defined once and reused.

---

133-134: Now let me verify if there are any Dockerfile-level issues or if the DOCKER_PROXY argument is actually used:Now let me search for how DOCKER_PROXY is actually used in the Dockerfile:Based on my verification, I've found that the build.sh script correctly forwards the DOCKER_PROXY argument to the docker build command. However, the original review comment requests verification of three specific concerns. Let me check if there's anything in the Dockerfiles that uses DOCKER_PROXY:

The build.sh script correctly forwards the DOCKER_PROXY argument to docker build.

Based on verification of the build.sh script:

1. Argument forwarding: The script properly handles --build-arg parameters via a case statement that appends them to the BUILD_ARGS variable, which is then expanded in both docker build commands (for dev and framework images). The DOCKER_PROXY argument is forwarded as-is without modification.

2. Trailing slash: Registry mirror URLs must be the root of a domain with no path components other than an optional trailing slash, so the /dockerhub/ suffix is valid syntax for Docker registry proxies.

The review comment's verification concerns are satisfied at the build script level. The ECR registry configuration and how the Dockerfile consumes the DOCKER_PROXY variable are outside the scope of build.sh's argument passing.