Jetson dockerfiles: OpenCV with GStreamer on JP62, add BuildKit cache mounts on JP62/JP71, bump JP51 OpenCV

[alexnorell]

Summary

• JP62: build OpenCV 4.13.0 from source with WITH_GSTREAMER=ON + CUDA, and add the runtime GStreamer stack (python3-gi, GIR typelibs, base plugins) so downstream code can build hardware capture/encode pipelines. Fixes the 4K USB camera workflow that was running at ~1.3 inference FPS against ~21 camera FPS — pre-PR cv2 was CPU-only and cv2.getBuildInformation() reported GStreamer: NO.
• JP62: drop the attempt to bake libgstnv*.so into the image. Those plugins live on the host JetPack BSP and are mounted in at runtime by nvidia-container-runtime via the CSVs under /etc/nvidia-container-runtime/host-files-for-container.d/. Container now ships only the cv2-facing half of the stack; the host provides the NVIDIA plugins.
• JP62: fix libnvdla_compiler.so source path (tegra/ -> nvidia/). The original glob in Fix missing libnvdla_compiler.so in Jetson 6.x TRT runtime #2201 silently matched zero files, so onnxruntime kept falling back to CPU on Jetson 6.x. Same one-liner as Fix libnvdla_compiler.so COPY path for Jetson 6.x runtime #2306 for jp61.
• JP62 + JP71: add BuildKit cache mounts to both Jetson dockerfiles — neither had any cache mounts before this PR, so warm rebuilds were doing the full 30-60 min OpenCV / PyTorch / torchvision / onnxruntime recompiles every run. New mounts cover apt plus per-build-tree directories for each heavy C++ compile (and the TRT .deb download on JP62). Each Jetson workflow also moves onto its own Depot project so the JP62 and JP71 builds stop evicting each other's NVMe state.
• JP51: OpenCV 4.12.0 -> 4.13.0 to stay aligned with JP62.
• All workflows: bump every GitHub Action in .github/workflows/ to its latest major (59 files touched). Done in one mechanical pass while we were already poking the Jetson workflows. See "Action version bumps" below.

Why cv2 was the bottleneck (JP62)

cv2.getBuildInformation() in the pre-PR JP62 image reported GStreamer: NO. The pip opencv-python wheel ships without GStreamer, so every frame went through YUYV uncompressed capture, CPU YUV-to-BGR, and the raw 4K stream got fed downstream to detection + visualization.

Even if cv2 had been compiled with GStreamer support, the runtime base l4t-cuda:12.6.11-runtime doesn't ship the JetPack multimedia stack, so the NVIDIA elements (nvv4l2decoder, nvvidconv, nvjpegenc/dec) wouldn't have been reachable anyway. That's why the fix is two-sided: build cv2 with GStreamer, and rely on the host BSP for the NVIDIA plugins.

JP71 ships the same pip cv2 wheel and would hit the same wall at 4K, but the GStreamer rebuild isn't ported there yet — only the build-perf and workflow changes apply to JP71 in this PR.

OpenCV build details (Dockerfile.onnx.jetson.6.2.0)

Builder:

• OpenCV 4.13.0 + opencv_contrib from source, WITH_GSTREAMER=ON, WITH_FFMPEG=ON, WITH_LIBV4L=ON, WITH_CUDA=ON, CUDA_ARCH_BIN=8.7. Pip's opencv-python / -headless / -contrib-python are uninstalled first; the wheel built from python_loader/ is installed in their place.
• Build-time cv2.getBuildInformation() assertion so any regression in detected flags fails the docker build, not the device.
• Per-platform OpenCV values pulled into ARGs (OPENCV_CUDA_ARCH, OPENCV_PYTHON_INSTALL_PATH, OPENCV_PYTHON_INCLUDE_DIR, OPENCV_PYTHON_VERSION) so porting this block to jp5.1.1 / jp7.1.0 is four ARG edits rather than cmake surgery.
• cv2 install-tree config rescue: ninja install writes correct-path config*.py, then pip install of the python_loader wheel overwrites them with BUILD-TREE paths that don't exist in the runtime stage and produce ImportError: recursion is detected during loading of "cv2". The fix snapshots the install-tree configs around the pip install and restores them after. A follow-up sanity check strips /build/ from sys.path and imports cv2 so this fails the docker build instead of the device.

Runtime stage adds libgstreamer1.0-0, gstreamer1.0-plugins-{base,good,tools}, python3-gi, gir1.2-gstreamer-1.0, gir1.2-gst-plugins-base-1.0, plus an inline comment explaining where the NVIDIA plugins come from.

Build perf: cache mounts added (Dockerfile.onnx.jetson.6.2.0 + Dockerfile.onnx.jetson.7.1.0)

Neither Jetson dockerfile had BuildKit cache mounts before this PR. Adding them on both:

• # syntax=docker/dockerfile:1.7 pinned so ARG interpolation in cache-mount id= works.
• Apt cache mounts (/var/cache/apt + /var/lib/apt, sharing=locked) on every apt RUN, ids scoped per JetPack x (builder|runtime) x arch. docker-clean disabled and Keep-Downloaded-Packages "true" so the cache is actually used. The trailing rm -rf /var/lib/apt/lists/* came out since that path is now the cache mount.
• Per-build-tree cache mounts on PyTorch, torchvision, onnxruntime (build/cuda12 on JP62, build/Linux on JP71), OpenCV (release/ on JP62), and the TRT .deb download on JP62. Each id is scoped by version + arch + SM so a version bump starts clean.
• git clone is now a separate RUN from the cache-mounted build RUN. The cache mount auto-creates its parent before the body executes, so a combined git clone && build hit destination path 'pytorch' already exists. Two RUNs now: clone (no mount), then build (cache mount overlays build/).
• OpenCV stays last in the JP62 builder on purpose. The upstream inference wheel installs aren't --no-deps, so moving OpenCV earlier risks opencv-python being reinstalled by a transitive dep and clobbering the from-source build. The build-dir cache mount makes the forced rebuild after COPY . . invalidation a fast ninja no-op rather than a 30-60 min recompile.

Workflows

.github/workflows/docker.jetson.6.2.0.yml and .github/workflows/docker.jetson.7.1.0.yml now point at their own Depot projects (JP62 2rp7mfjw7q, JP71 v1xzfwkc4b) instead of sharing grl7ffzxd7. Sharing one project meant the two builds were evicting each other's NVMe layers and cache-mount state on every run.

Action version bumps

Everything in .github/workflows/ got bumped to its latest major in a single pass:

Action	Old	New
actions/cache	v3	v5
actions/checkout	v2 / v3 / v4	v6
actions/create-github-app-token	v1	v3
actions/setup-node	v3	v6
actions/setup-python	v2 / v5	v6
actions/upload-artifact	v4	v7
aws-actions/amazon-ecr-login	v1	v2
aws-actions/configure-aws-credentials	v2	v6
dcarbone/install-jq-action	v2.1.0	v3.2.0
digicert/ssm-code-signing	v1.0.0	v1.2.1
docker/login-action	v2 / v3	v4
docker/setup-buildx-action	v2	v4
docker/setup-qemu-action	v2	v4
google-github-actions/auth	v2	v3
google-github-actions/setup-gcloud	v2	v3

Left as-is:

• depot/setup-action@v1 and depot/build-push-action@v1 already track the floating major (latest is v1.7.1 / v1.17.0 within v1).
• actions/upload-release-asset@v1 — still latest major; the upstream is archived but the v1 release is what it is.
• pypa/gh-action-pypi-publish@release/v1 — upstream's recommended stable-channel ref, kept verbatim.

Most bumps are pure Node-version updates (Node 20 -> 24) and won't change behaviour. The two worth eyeballing in CI before merge are actions/upload-artifact (v4 -> v7 is a multi-major jump, though we only use it with name / path / if-no-files-found / retention-days which have been stable) and aws-actions/configure-aws-credentials (v2 -> v6, used with aws-region + access-key inputs which are also stable).

Test plan

• JP62 build succeeds and pushes a tag: gh workflow run docker.jetson.6.2.0.yml --ref fix/jp62-opencv-gstreamer-nvidia -f force_push=true -f custom_tag=jp62-gstreamer-nvidia
• JP71 build succeeds: same dispatch against docker.jetson.7.1.0.yml
• On a JP62 device with nvidia-container-runtime configured: python3 -c "import cv2; print(cv2.getBuildInformation())" reports GStreamer: YES, FFMPEG: YES, CUDA: YES
• gst-inspect-1.0 nvv4l2decoder resolves inside the container (relies on host CSV mounts)
• gst-inspect-1.0 nvvidconv resolves
• gst-inspect-1.0 nvjpegenc resolves
• python3 -c "from gi.repository import Gst; Gst.init(None)" succeeds
• Inference FPS on the 4K USB camera + detection workflow comfortably above the 1.3 FPS baseline
• Second JP62 build (warm cache) skips most apt downloads and finishes the OpenCV step in seconds rather than tens of minutes — actually came back even better: 2 min total, every step hit Depot's docker layer cache (#X CACHED), so the cache mounts didn't need to engage. Layer-cache eviction (a real source change touching COPY . .) is what will exercise the cache mounts; not yet observed.
• Second JP71 build (warm cache) hits cached PyTorch / torchvision / onnxruntime build trees — same outcome as JP62: 3 min total, served from Depot layer cache.