Update bev fusion image tag and health check cmd

[aotianw-nv]

Description

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[greptile-apps]

Greptile Summary

This PR bumps the BEV_FUSION_MV3DT_TAG in the warehouse-operations .env from 3.2.0-26.05.1 to 3.2.0-26.05.3 and replaces the measurement-fusion health check from the test -f shell built-in to a python3 one-liner — presumably because test is absent from the new image.

• .env: Both the active multi-arch tag and the commented SBSA variant are correctly bumped to 3.2.0-26.05.3.
• compose.yaml: Health check logic is equivalent, but the inline default tag on line 41 (BEV_FUSION_MV3DT_TAG:-3.2.0-26.05.1) was not updated. Deployments that do not source the warehouse-operations .env will pull the old image and run the new python3 health check — which may not be available in the 26.05.1 image, causing the health check to fail permanently. This was flagged in earlier review rounds and remains unaddressed.
• warehouse-mv3dt-app/warehouse-mv3dt-app.yml (not in diff): also overrides the image with the same stale 3.2.0-26.05.1 inline default and was not updated.

Confidence Score: 4/5

The .env update is correct, but the inline default tag in compose.yaml was not updated alongside it, leaving a mismatch that can break health checks for any deployment that does not source the warehouse-operations .env.

The inline default BEV_FUSION_MV3DT_TAG:-3.2.0-26.05.1 in compose.yaml (line 41) was not bumped to match the .env change. Because the health check was simultaneously switched to use python3, any deployment pulling the old 26.05.1 image via that stale default will run a health check that requires python3 — which may not exist in that image — causing the container to never become healthy. This was flagged in earlier reviews and remains unresolved.

deploy/docker/services/rtvi/rtvi-cv/rtvi-cv-mv3dt/compose.yaml — the inline default image tag on line 41 still references 3.2.0-26.05.1 and needs to be updated to 3.2.0-26.05.3 to match the .env change.

Important Files Changed

Filename	Overview
deploy/docker/industry-profiles/warehouse-operations/.env	Bumps BEV_FUSION_MV3DT_TAG from 3.2.0-26.05.1 to 3.2.0-26.05.3 for both multi-arch and SBSA variants; change is correct and self-consistent within this file.
deploy/docker/services/rtvi/rtvi-cv/rtvi-cv-mv3dt/compose.yaml	Replaces test -f health check with a python3 one-liner; the inline default image tag on line 41 remains 3.2.0-26.05.1, meaning deployments without the warehouse-operations .env will pull the old image but run the new health check that requires python3, which may not be present in that image.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Docker Compose Start] --> B{BEV_FUSION_MV3DT_TAG set in env?}
    B -- Yes, from .env --> C[Pull image: 3.2.0-26.05.3\nPython3 available ✅]
    B -- No, use inline default --> D[Pull image: 3.2.0-26.05.1\nPython3 availability unknown ⚠️]
    C --> E[Health check runs:\npython3 -c 'check /tmp/fusion_ready']
    D --> E
    E --> F{python3 found in image?}
    F -- Yes --> G{/tmp/fusion_ready exists?}
    F -- No --> H[Health check fails permanently ❌]
    G -- Yes --> I[Container marked healthy ✅]
    G -- No, retry up to 30x --> G

Loading

_{Reviews (3): Last reviewed commit: "Update bev fusion image tag and health c..." | Re-trigger Greptile}

[aotianw-nv]

/ok to test 1323eaa

[github-actions]

🟡 Helm drift check — no helm counterpart

The in-scope docker change in this PR is to:

• deploy/docker/services/rtvi/rtvi-cv/rtvi-cv-mv3dt/compose.yaml (healthcheck command form change on measurement-fusion)

This compose path has no corresponding helm chart on develop (the rtvi-cv-mv3dt variant has never been mirrored under deploy/helm/services/rtvi/charts/, only the base rtvi-cv is). Per the helm-sync agent's rules I won't scaffold a new chart from scratch — that's a human-driven decision.

The other changed file (deploy/docker/industry-profiles/warehouse-operations/.env) is out of scope for helm-sync.

If the mv3dt variant should have a kubernetes deployment, please add the chart manually; otherwise, this check needs a human to either (a) acknowledge mv3dt is docker-compose-only and exempt this path, or (b) produce the chart. Re-running CI on the next mirror push will reflect the resolution.

[kartikayt-nvidia]

/ok to test 3360b6a

[kartikayt-nvidia]

/ok to test 7504332

[bp-sre-sonarqube]

Quality Gate passed for 'video-search-and-summarization-ui'

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarQube

[bp-sre-sonarqube]

Quality Gate passed for 'video-search-and-summarization-skills'

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarQube

[bp-sre-sonarqube]

Quality Gate passed for 'video-search-and-summarization-agent'

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarQube