RHOAIENG-27435: Create Rocm Pytorch Python 3.12 #1248
Conversation
|
Caution Review failedThe pull request is closed. WalkthroughThis change set primarily addresses merge conflicts and dependency updates in various Changes
Suggested labels
Suggested reviewers
📜 Recent review detailsConfiguration used: .coderabbit.yaml ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (7)
✨ Finishing Touches
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 15
🔭 Outside diff range comments (7)
codeserver/ubi9-python-3.11/requirements.txt (1)
597-759: Second merge-conflict block left in place (pillow / platformdirs)Another full conflict block remains, duplicating two different
pillow&platformdirspins.
Same fatal build error risk as above.-<<<<<<< HEAD -pillow==11.1.0 … -platformdirs==4.3.6 … -======= +pillow==11.2.1 … # decide which versions you actually want +platformdirs==4.3.8 … ->>>>>>> 6cd9ddb8dfc226e673fb229d12238159900806efPick the intended versions (usually the newer ones) and delete the markers, or regenerate the file from lock-data.
jupyter/minimal/ubi9-python-3.11/requirements.txt (1)
615-827: Remove merge-conflict markers from requirements.txtThe file jupyter/minimal/ubi9-python-3.11/requirements.txt still contains unresolved Git conflict markers (
<<<<<<<,=======,>>>>>>>), which will breakpip install. Please:
- Remove all conflict markers and duplicated entries.
- Keep only the intended final versions:
- mistune==3.1.3
- multidict==6.6.2
- Verify there are no leftover
<<<<<<<,=======, or>>>>>>>lines around these dependencies.Location to fix:
- jupyter/minimal/ubi9-python-3.11/requirements.txt, lines 615–827
Example cleanup:
-<<<<<<< HEAD -mistune==3.1.2; python_version >= '3.8' \ - --hash=sha256:4b4773... -… -multidict==6.2.0; python_version >= '3.9' \ - --hash=sha256:0085b0... -… -======= mistune==3.1.3; python_version >= '3.8' \ --hash=sha256:1a3231... … multidict==6.6.2; python_version >= '3.9' \ --hash=sha256:03f20d... … ->>>>>>> <commit-id>After cleaning up, run:
pip install -r jupyter/minimal/ubi9-python-3.11/requirements.txt pip check(or the repo’s sync script) to ensure all dependencies and lockfiles stay consistent.
runtimes/tensorflow/ubi9-python-3.11/requirements.txt (1)
697-705: Merge conflict still present – pick one version and delete markersThe block for
googleapis-common-protosstill contains<<<<<<< HEAD … ======= … >>>>>>>markers. Until this is resolved the image build will fail.-<<<<<<< HEAD -googleapis-common-protos==1.69.2; python_version >= '3.7' \ - --hash=<sha256-old-1> \ - --hash=<sha256-old-2> -======= googleapis-common-protos==1.70.0; python_version >= '3.7' \ --hash=<sha256-new-1> \ --hash=<sha256-new-2> ->>>>>>> 6cd9ddb8dfc226e673fb229d12238159900806ef(Keep the two hashes that belong to version 1.70.0, delete the rest.)
After fixing, run
scripts/sync-requirements-txt.shagain so hashes stay consistent.runtimes/rocm-tensorflow/ubi9-python-3.11/requirements.txt (1)
700-708: Merge conflict still present forgoogleapis-common-protosThe
<<<<<<< HEAD,=======,>>>>>>>block must be resolved. Decide on one version (1.70.0 is the latest referenced in other updated images) and remove markers:-<<<<<<< HEAD -googleapis-common-protos==1.69.2; python_version >= '3.7' \ - --hash=sha256:0b30452ff9c7a27d80bfc5718954063e8ab53dd3697093d3bc99581f5fd24212 \ - --hash=sha256:3e1b904a27a33c821b4b749fd31d334c0c9c30e6113023d495e48979a3dc9c5f -======= googleapis-common-protos==1.70.0; python_version >= '3.7' \ --hash=sha256:0e1b44e0ea153e6594f9f394fef15193a68aaaea2d843f83e2742717ca753257 \ --hash=sha256:b8bfcca8c25a2bb253e0e0b0adaf8c00773e5e6af6fd92397576680b807e0fd8 ->>>>>>> ...After removal, bump hashes if you choose another version.
jupyter/pytorch/ubi9-python-3.11/requirements.txt (1)
804-885: Unresolved merge-conflict markers breakpipparsing.The file still contains
<<<<<<<,=======, and>>>>>>>markers and duplicated stanza blocks for
google-crc32c,google-resumable-media, andgoogleapis-common-protos.
Anypip install -rwill fail, and image builds will explode early.<<<<<<< HEAD -google-crc32c==1.7.0 -... -googleapis-common-protos==1.69.2 ======= +google-crc32c==1.7.1 # align with other images / upstream +... +googleapis-common-protos==1.70.0 >>>>>>> 6cd9ddb8dfc226e673fb229d12238159900806efStrip the markers and keep one consistent version triple (the
HEADside matches other 3.12 images, so prefer it).
Failing to do so blocks every downstream pipeline step.Also applies to: 2140-2147
jupyter/datascience/ubi9-python-3.11/requirements.txt (1)
800-883: Unresolved merge-conflict markers – build will fail
<<<<<<< HEAD,=======,>>>>>>>and the duplicated package blocks must be removed.
Leaving these markers inrequirements.txtbreaks parsing and will abort anypip install, blocking CI and image builds.Suggested minimal fix (keep the newer versions used everywhere else in the repo):
-<<<<<<< HEAD -google-crc32c==1.7.0 ... -... -googleapis-common-protos==1.69.2 ... -======= # keep one copy of google-resumable-media (identical in both halves) google-crc32c==1.7.1 ... ... googleapis-common-protos==1.70.0 ... ->>>>>>> 6cd9ddb8dfc226e673fb229d12238159900806efAfter applying, ensure there is only ONE occurrence of each of:
google-resumable-media==2.7.2 google-crc32c==1.7.1 googleapis-common-protos==1.70.0Run
pip compile/ the repo’s sync script again to regenerate hashes if needed.jupyter/rocm/pytorch/ubi9-python-3.11/requirements.txt (1)
804-885: Resolve merge conflicts across all dependency filesMultiple
<<<<<<<…=======…>>>>>>>markers remain in requirements.txt and Pipfile.lock across the repo, blocking anypip installor lockfile parsing. You must remove all conflict markers, pick the correct versions, and regenerate hashes/locks consistently.Files affected (non-exhaustive; see full list from
rg '^(<<<<<<<|=======|>>>>>>>)'):• jupyter/minimal/ubi9-python-3.11/requirements.txt (lines 615, 712)
• jupyter/rocm/tensorflow/ubi9-python-3.11/Pipfile.lock (lines 1212–1224)
• jupyter/rocm/pytorch/ubi9-python-3.12/requirements.txt (lines 804–845, 2081)
• jupyter/rocm/pytorch/ubi9-python-3.11/requirements.txt (lines 804–845, 2081)
• runtimes//requirements.txt and Pipfile.lock in tensorflow, rocm-tensorflow, rocm-pytorch, datascience, pytorch
• jupyter//requirements.txt and Pipfile.lock in pytorch, datascience
• codeserver/ubi9-python-3.11/{requirements.txt,Pipfile.lock}Action items:
• Remove all<<<<<<<,=======,>>>>>>>blocks by choosing the intended dependency versions (e.g.google-crc32c==1.7.1,googleapis-common-protos==1.70.0).
• In each requirements.txt, leave only one set of lines and drop markers.
• In each Pipfile.lock, repeat lock generation (e.g.pipenv lockinside the appropriate UBI9 container for linux/amd64 & Python 3.11/3.12).
• After cleanup, run:
bash ./scripts/sync-requirements-txt.sh pipenv lock rg --line-number '^(<<<<<<<|=======|>>>>>>>)' || echo "No conflict markers remain"This is blocking the build/test pipeline—please resolve all merges before proceeding.
🧹 Nitpick comments (7)
jupyter/rocm/pytorch/ubi9-python-3.12/kustomize/base/kustomization.yaml (1)
4-15: Explicitly pin the image digest to guarantee reproducibility
Tag-only references (newTag: rocm-jupyter-pytorch-ubi9-python-3.12) can drift once the registry is overwritten. To make future rebuilds deterministic, add the immutable digest:- newTag: rocm-jupyter-pytorch-ubi9-python-3.12 + newTag: rocm-jupyter-pytorch-ubi9-python-3.12 + digest: sha256:<insert_actual_digest_here>jupyter/rocm/pytorch/ubi9-python-3.12/de-vendor-torch.sh (2)
9-12: DeriveTORCHLIBpath dynamically to survive layout changes
Hard-coding/opt/app-root/lib/${PYTHON}/site-packagescouples the script to a single image layout. Use Python’s own introspection to locate torch/lib:-PYTHON=python3.12 -ROCMLIB=/opt/rocm/lib -TORCHLIB=/opt/app-root/lib/${PYTHON}/site-packages/torch/lib +PYTHON=python3.12 +ROCMLIB=/opt/rocm/lib +TORCHLIB="$(${PYTHON} - <<'PY' +import importlib.util, pathlib, sys +spec = importlib.util.find_spec("torch") +print(pathlib.Path(spec.origin).parent / "lib") +PY +)"This avoids silent breakage if the base image upgrades its sysroot.
13-36: Guard against missing system libraries to fail fast & clearly
set -eaborts on the firstln -sfthat encounters a non-existent source. Add a short existence check to emit a helpful error instead of a cryptic “No such file”:for lib in \ libamd_comgr.so.2 libamdhip64.so.6 libhipblas.so.2 ... ; do [ -e "${ROCMLIB}/${lib}" ] || { echo "Missing ${lib}" >&2; exit 1; } donejupyter/rocm/pytorch/ubi9-python-3.12/kustomize/base/statefulset.yaml (1)
52-58: Right-size default resources or make them configurable
Hard-wiring500m/2Girequests & limits hampers multi-tenant clusters running GPU/ROCm workloads whose memory footprint differs greatly. Consider exposing configurable values via kustomizevarsor lowering defaults (e.g., 250m/512Mi).jupyter/rocm/pytorch/ubi9-python-3.12/Pipfile (2)
21-35: Pincodeflare-sdkusing==to avoid breaking API changes
codeflare-sdkis fast-moving and has introduced backwards-incompatible changes in minor releases. For stability match the pattern used for core Jupyter packages:-codeflare-sdk = "~=0.29.0" +codeflare-sdk = "==0.29.0"
42-57: Document divergence from TrustyAI’s jupyter-bokeh pinning
TrustyAI images still requirejupyter-bokeh~=3.0.5. Installing 4.x variants side-by-side in a multi-image environment can lead to dependency resolution fights when users switch kernels. Add a comment or align the version to prevent hidden conflicts.jupyter/rocm/pytorch/ubi9-python-3.12/test/test_notebook.ipynb (1)
164-169: Add cleanup for ONNX export test.The test creates an ONNX file but doesn't clean it up, which could cause issues in repeated test runs.
# Check if the ONNX file exists self.assertTrue(os.path.exists(onnx_path), f"ONNX file {onnx_path} not found") + + # Clean up the generated file + if os.path.exists(onnx_path): + os.remove(onnx_path)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (9)
codeserver/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockjupyter/datascience/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockjupyter/rocm/pytorch/ubi9-python-3.12/Pipfile.lockis excluded by!**/*.lockjupyter/rocm/tensorflow/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockruntimes/datascience/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockruntimes/pytorch/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockruntimes/rocm-pytorch/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockruntimes/rocm-tensorflow/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockruntimes/tensorflow/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lock
📒 Files selected for processing (17)
codeserver/ubi9-python-3.11/requirements.txt(3 hunks)jupyter/datascience/ubi9-python-3.11/requirements.txt(2 hunks)jupyter/minimal/ubi9-python-3.11/requirements.txt(1 hunks)jupyter/pytorch/ubi9-python-3.11/requirements.txt(2 hunks)jupyter/rocm/pytorch/ubi9-python-3.11/requirements.txt(2 hunks)jupyter/rocm/pytorch/ubi9-python-3.12/Dockerfile.rocm(1 hunks)jupyter/rocm/pytorch/ubi9-python-3.12/Pipfile(1 hunks)jupyter/rocm/pytorch/ubi9-python-3.12/de-vendor-torch.sh(1 hunks)jupyter/rocm/pytorch/ubi9-python-3.12/kustomize/base/kustomization.yaml(1 hunks)jupyter/rocm/pytorch/ubi9-python-3.12/kustomize/base/service.yaml(1 hunks)jupyter/rocm/pytorch/ubi9-python-3.12/kustomize/base/statefulset.yaml(1 hunks)jupyter/rocm/pytorch/ubi9-python-3.12/test/test_notebook.ipynb(1 hunks)runtimes/datascience/ubi9-python-3.11/requirements.txt(1 hunks)runtimes/pytorch/ubi9-python-3.11/requirements.txt(1 hunks)runtimes/rocm-pytorch/ubi9-python-3.11/requirements.txt(1 hunks)runtimes/rocm-tensorflow/ubi9-python-3.11/requirements.txt(2 hunks)runtimes/tensorflow/ubi9-python-3.11/requirements.txt(2 hunks)
🧰 Additional context used
🧠 Learnings (18)
📓 Common learnings
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing `runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml` file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1230
File: jupyter/minimal/ubi9-python-3.12/Dockerfile.cpu:21-24
Timestamp: 2025-07-01T06:48:13.154Z
Learning: jiridanek creates comprehensive follow-up issues from review comments that expand scope appropriately, include clear acceptance criteria, proper backlinks, and structured implementation guidance. Issue #1241 demonstrates this by turning a specific oc client checksum concern into a thorough security enhancement plan covering all downloaded binaries across the Python 3.12 implementation.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-20T11:51:59.716Z
Learning: This project follows the practice of associating PRs with Jira tickets from https://issues.redhat.com for traceability between requirements, release process, and product documentation. This is critical for enterprise software development compliance and cross-team coordination.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1247
File: .github/workflows/build-notebooks-TEMPLATE.yaml:50-53
Timestamp: 2025-07-01T14:36:52.815Z
Learning: In the opendatahub-io/notebooks repository, the test runner's Python version (configured in GitHub Actions UV setup) intentionally doesn't need to match the Python version of the container images being tested. jiridanek's team uses Python 3.12 for running tests while images may use different Python versions (like 3.11), and this approach works fine since the test code is separate from the application code running inside the containers.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1230
File: jupyter/pytorch/ubi9-python-3.12/kustomize/components/accelerator/pod-patch.yaml:11-22
Timestamp: 2025-06-30T14:36:53.890Z
Learning: The pod-patch.yaml file in jupyter/pytorch/ubi9-python-3.12/kustomize/components/accelerator/ is used only for running tests, not production deployments. This affects the risk assessment for resource management configurations like sizeLimit on emptyDir volumes.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1230
File: jupyter/minimal/ubi9-python-3.12/Dockerfile.rocm:43-55
Timestamp: 2025-07-01T06:48:21.070Z
Learning: When security concerns are raised during PR reviews in opendatahub-io/notebooks, comprehensive follow-up issues are created (often by CodeRabbit) to track all related security enhancements with clear acceptance criteria and implementation guidance. This ensures security improvements are systematically addressed in dedicated efforts rather than blocking current deliverables.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1151
File: jupyter/tensorflow/ubi9-python-3.12/kustomize/base/statefulset.yaml:11-17
Timestamp: 2025-07-01T06:50:37.115Z
Learning: jiridanek manages StatefulSet selector issues systematically across multiple images in opendatahub-io/notebooks. When the same configuration issue (empty spec.selector and template.metadata.labels) appears in different images like jupyter/minimal and jupyter/tensorflow, he tracks them under a single coordinated effort rather than creating duplicate issues for each affected image.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatahub-io/notebooks. They run `pipenv lock` inside UBI9 containers with specific platform arguments (`--platform=linux/amd64 --python-version 3.12`) to avoid host OS dependency conflicts when generating Pipfile.lock files.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: In the opendatahub-io/notebooks repository, TensorFlow packages with `extras = ["and-cuda"]` can cause build conflicts on macOS due to platform-specific CUDA packages. When the Dockerfile installs CUDA system-wide, removing the extras and letting TensorFlow find CUDA at runtime resolves these conflicts.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1154
File: manifests/base/jupyter-pytorch-notebook-imagestream.yaml:0-0
Timestamp: 2025-06-16T11:06:33.139Z
Learning: In the opendatahub-io/notebooks repository, N-1 versions of images in manifest files (like imagestream.yaml files) should not be updated regularly. The versions of packages like codeflare-sdk in N-1 images are frozen to what was released when the image was moved from N to N-1 version. N-1 images are only updated for security vulnerabilities of packages, not for regular version bumps. This is why the version of packages in N-1 images may be quite old compared to the latest N version.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1154
File: manifests/base/jupyter-tensorflow-notebook-imagestream.yaml:45-45
Timestamp: 2025-06-13T08:34:01.300Z
Learning: When updating dependency versions in `manifests/base/*-imagestream.yaml`, the project convention is to modify only the newest tag (e.g., "2025.1") and intentionally leave earlier tags (e.g., "2024.2") unchanged.
jupyter/rocm/pytorch/ubi9-python-3.12/kustomize/base/service.yaml (2)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing `runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml` file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1230
File: jupyter/pytorch/ubi9-python-3.12/kustomize/components/accelerator/pod-patch.yaml:11-22
Timestamp: 2025-06-30T14:36:53.890Z
Learning: The pod-patch.yaml file in jupyter/pytorch/ubi9-python-3.12/kustomize/components/accelerator/ is used only for running tests, not production deployments. This affects the risk assessment for resource management configurations like sizeLimit on emptyDir volumes.
jupyter/rocm/pytorch/ubi9-python-3.12/de-vendor-torch.sh (1)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing `runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml` file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
jupyter/rocm/pytorch/ubi9-python-3.12/Pipfile (5)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing `runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml` file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatahub-io/notebooks. They run `pipenv lock` inside UBI9 containers with specific platform arguments (`--platform=linux/amd64 --python-version 3.12`) to avoid host OS dependency conflicts when generating Pipfile.lock files.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/datascience/ubi9-python-3.11/Pipfile:34-36
Timestamp: 2025-06-28T14:13:27.890Z
Learning: In the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pattern: core `jupyterlab` package uses exact pinning (==) across all notebook images to ensure UI consistency, while JupyterLab extensions and all server components (jupyter-server, jupyter-server-proxy, jupyter-server-terminals) use compatible release (~=) pinning to allow automatic security updates and bug fixes while maintaining API compatibility.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
jupyter/rocm/pytorch/ubi9-python-3.12/kustomize/base/statefulset.yaml (7)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T07:11:44.903Z
Learning: Resource limits in StatefulSet manifests in opendatahub-io/notebooks are configured for testing purposes, not production deployments. This affects risk assessment when reviewing resource configurations like memory and CPU limits.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing `runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml` file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1151
File: jupyter/tensorflow/ubi9-python-3.12/kustomize/base/statefulset.yaml:11-17
Timestamp: 2025-07-01T06:50:37.115Z
Learning: jiridanek manages StatefulSet selector issues systematically across multiple images in opendatahub-io/notebooks. When the same configuration issue (empty spec.selector and template.metadata.labels) appears in different images like jupyter/minimal and jupyter/tensorflow, he tracks them under a single coordinated effort rather than creating duplicate issues for each affected image.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1151
File: jupyter/tensorflow/ubi9-python-3.12/kustomize/base/statefulset.yaml:11-17
Timestamp: 2025-07-01T06:50:37.115Z
Learning: StatefulSet selector issue with empty `spec.selector: {}` is a known systemic problem across multiple images in opendatahub-io/notebooks repository, tracked in issue #1236. This affects multiple StatefulSet manifests and is being addressed centrally rather than in individual PRs.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1230
File: jupyter/pytorch/ubi9-python-3.12/kustomize/components/accelerator/pod-patch.yaml:11-22
Timestamp: 2025-06-30T14:36:53.890Z
Learning: The pod-patch.yaml file in jupyter/pytorch/ubi9-python-3.12/kustomize/components/accelerator/ is used only for running tests, not production deployments. This affects the risk assessment for resource management configurations like sizeLimit on emptyDir volumes.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1230
File: jupyter/pytorch/ubi9-python-3.12/kustomize/base/statefulset.yaml:54-60
Timestamp: 2025-06-30T14:43:08.138Z
Learning: Issue #1212 in opendatahub-io/notebooks demonstrates that missing securityContext configuration (allowPrivilegeEscalation, runAsNonRoot, seccompProfile) causes runtime pods to fail reaching ready state and timeout after 300s on OpenShift due to PodSecurity policy violations.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: Runtime deployment tests in opendatahub-io/notebooks may show PodSecurity warnings about allowPrivilegeEscalation, capabilities, runAsNonRoot, and seccompProfile settings. These warnings occur on OpenShift but not on GitHub Actions because GitHub Actions uses upstream Kubernetes without SecurityContextConstraints (SCC).
jupyter/rocm/pytorch/ubi9-python-3.12/Dockerfile.rocm (9)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing `runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml` file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: In the opendatahub-io/notebooks repository, TensorFlow packages with `extras = ["and-cuda"]` can cause build conflicts on macOS due to platform-specific CUDA packages. When the Dockerfile installs CUDA system-wide, removing the extras and letting TensorFlow find CUDA at runtime resolves these conflicts.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatahub-io/notebooks. They run `pipenv lock` inside UBI9 containers with specific platform arguments (`--platform=linux/amd64 --python-version 3.12`) to avoid host OS dependency conflicts when generating Pipfile.lock files.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1151
File: jupyter/tensorflow/ubi9-python-3.12/kustomize/base/statefulset.yaml:11-17
Timestamp: 2025-07-01T06:50:37.115Z
Learning: jiridanek manages StatefulSet selector issues systematically across multiple images in opendatahub-io/notebooks. When the same configuration issue (empty spec.selector and template.metadata.labels) appears in different images like jupyter/minimal and jupyter/tensorflow, he tracks them under a single coordinated effort rather than creating duplicate issues for each affected image.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1230
File: jupyter/pytorch/ubi9-python-3.12/kustomize/components/accelerator/pod-patch.yaml:11-22
Timestamp: 2025-06-30T14:35:34.805Z
Learning: In the opendatahub-io/notebooks repository, mounting emptyDir volumes over /opt/app-root/src is intentional behavior that matches production deployment patterns where odh-dashboard mounts empty PVCs at this location (the $HOME directory). This mounting is expected to hide base image content.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1154
File: manifests/base/jupyter-pytorch-notebook-imagestream.yaml:0-0
Timestamp: 2025-06-16T11:06:33.139Z
Learning: In the opendatahub-io/notebooks repository, N-1 versions of images in manifest files (like imagestream.yaml files) should not be updated regularly. The versions of packages like codeflare-sdk in N-1 images are frozen to what was released when the image was moved from N to N-1 version. N-1 images are only updated for security vulnerabilities of packages, not for regular version bumps. This is why the version of packages in N-1 images may be quite old compared to the latest N version.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1230
File: jupyter/pytorch/ubi9-python-3.12/kustomize/base/statefulset.yaml:54-60
Timestamp: 2025-06-30T14:43:08.138Z
Learning: Issue #1212 in opendatahub-io/notebooks demonstrates that missing securityContext configuration (allowPrivilegeEscalation, runAsNonRoot, seccompProfile) causes runtime pods to fail reaching ready state and timeout after 300s on OpenShift due to PodSecurity policy violations.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: Runtime deployment tests in opendatahub-io/notebooks may show PodSecurity warnings about allowPrivilegeEscalation, capabilities, runAsNonRoot, and seccompProfile settings. These warnings occur on OpenShift but not on GitHub Actions because GitHub Actions uses upstream Kubernetes without SecurityContextConstraints (SCC).
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: OpenShift CI infrastructure issues in opendatahub-io/notebooks can manifest as "ContainerFailed one or more containers exited" errors in release steps, or as "Entrypoint received interrupt: terminated" messages when pods are killed during CI runs. These are typically infrastructure-level issues rather than code problems.
runtimes/pytorch/ubi9-python-3.11/requirements.txt (5)
undefined
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: In the opendatahub-io/notebooks repository, TensorFlow packages with extras = ["and-cuda"] can cause build conflicts on macOS due to platform-specific CUDA packages. When the Dockerfile installs CUDA system-wide, removing the extras and letting TensorFlow find CUDA at runtime resolves these conflicts.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI 0.6.1 (latest version as of June 2025) has a hard dependency constraint on jupyter-bokeh~=3.0.5, preventing upgrades to jupyter-bokeh 4.x in notebook images that include TrustyAI. This requires either waiting for TrustyAI to update their dependency or excluding TrustyAI from jupyter-bokeh upgrades.
</retrieved_learning>
runtimes/datascience/ubi9-python-3.11/requirements.txt (6)
undefined
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: The jupyter-bokeh pinning to 3.0.5 in TrustyAI notebook image was not due to TrustyAI code compatibility issues, but because the trustyai package itself explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency, causing pip dependency resolution conflicts when trying to upgrade to jupyter-bokeh 4.x.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI 0.6.1 (latest version as of June 2025) has a hard dependency constraint on jupyter-bokeh~=3.0.5, preventing upgrades to jupyter-bokeh 4.x in notebook images that include TrustyAI. This requires either waiting for TrustyAI to update their dependency or excluding TrustyAI from jupyter-bokeh upgrades.
</retrieved_learning>
runtimes/rocm-pytorch/ubi9-python-3.11/requirements.txt (5)
undefined
<retrieved_learning>
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: In the opendatahub-io/notebooks repository, TensorFlow packages with extras = ["and-cuda"] can cause build conflicts on macOS due to platform-specific CUDA packages. When the Dockerfile installs CUDA system-wide, removing the extras and letting TensorFlow find CUDA at runtime resolves these conflicts.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI 0.6.1 (latest version as of June 2025) has a hard dependency constraint on jupyter-bokeh~=3.0.5, preventing upgrades to jupyter-bokeh 4.x in notebook images that include TrustyAI. This requires either waiting for TrustyAI to update their dependency or excluding TrustyAI from jupyter-bokeh upgrades.
</retrieved_learning>
runtimes/rocm-tensorflow/ubi9-python-3.11/requirements.txt (4)
undefined
<retrieved_learning>
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: In the opendatahub-io/notebooks repository, TensorFlow packages with extras = ["and-cuda"] can cause build conflicts on macOS due to platform-specific CUDA packages. When the Dockerfile installs CUDA system-wide, removing the extras and letting TensorFlow find CUDA at runtime resolves these conflicts.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI 0.6.1 (latest version as of June 2025) has a hard dependency constraint on jupyter-bokeh~=3.0.5, preventing upgrades to jupyter-bokeh 4.x in notebook images that include TrustyAI. This requires either waiting for TrustyAI to update their dependency or excluding TrustyAI from jupyter-bokeh upgrades.
</retrieved_learning>
jupyter/rocm/pytorch/ubi9-python-3.12/kustomize/base/kustomization.yaml (5)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing `runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml` file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1230
File: jupyter/pytorch/ubi9-python-3.12/kustomize/components/accelerator/pod-patch.yaml:11-22
Timestamp: 2025-06-30T14:36:53.890Z
Learning: The pod-patch.yaml file in jupyter/pytorch/ubi9-python-3.12/kustomize/components/accelerator/ is used only for running tests, not production deployments. This affects the risk assessment for resource management configurations like sizeLimit on emptyDir volumes.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/rocm/pytorch/ubi9-python-3.11/requirements.txt:987-989
Timestamp: 2025-06-28T15:06:03.344Z
Learning: In the opendatahub-io/notebooks repository, checks for broken links and missing files in kustomization manifests are already performed by `ci/kustomize.sh`, which is invoked from `.github/workflows/code-quality.yaml` (lines 112–116). No additional pytest is needed for this purpose.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1151
File: jupyter/tensorflow/ubi9-python-3.12/kustomize/base/statefulset.yaml:11-17
Timestamp: 2025-07-01T06:50:37.115Z
Learning: jiridanek manages StatefulSet selector issues systematically across multiple images in opendatahub-io/notebooks. When the same configuration issue (empty spec.selector and template.metadata.labels) appears in different images like jupyter/minimal and jupyter/tensorflow, he tracks them under a single coordinated effort rather than creating duplicate issues for each affected image.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1151
File: jupyter/tensorflow/ubi9-python-3.12/kustomize/base/statefulset.yaml:11-17
Timestamp: 2025-07-01T06:50:37.115Z
Learning: StatefulSet selector issue with empty `spec.selector: {}` is a known systemic problem across multiple images in opendatahub-io/notebooks repository, tracked in issue #1236. This affects multiple StatefulSet manifests and is being addressed centrally rather than in individual PRs.
jupyter/rocm/pytorch/ubi9-python-3.12/test/test_notebook.ipynb (5)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing `runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml` file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1247
File: .github/workflows/build-notebooks-TEMPLATE.yaml:50-53
Timestamp: 2025-07-01T14:36:52.815Z
Learning: In the opendatahub-io/notebooks repository, the test runner's Python version (configured in GitHub Actions UV setup) intentionally doesn't need to match the Python version of the container images being tested. jiridanek's team uses Python 3.12 for running tests while images may use different Python versions (like 3.11), and this approach works fine since the test code is separate from the application code running inside the containers.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: Test failures in opendatahub-io/notebooks should be categorized as either repository bugs (code/configuration issues) or infrastructure issues (CI platform problems) for proper diagnosis and resolution.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/rocm/pytorch/ubi9-python-3.11/requirements.txt:987-989
Timestamp: 2025-06-28T15:06:03.344Z
Learning: In the opendatahub-io/notebooks repository, checks for broken links and missing files in kustomization manifests are already performed by `ci/kustomize.sh`, which is invoked from `.github/workflows/code-quality.yaml` (lines 112–116). No additional pytest is needed for this purpose.
codeserver/ubi9-python-3.11/requirements.txt (6)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: The jupyter-bokeh pinning to 3.0.5 in TrustyAI notebook image was not due to TrustyAI code compatibility issues, but because the trustyai package itself explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency, causing pip dependency resolution conflicts when trying to upgrade to jupyter-bokeh 4.x.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI 0.6.1 (latest version as of June 2025) has a hard dependency constraint on jupyter-bokeh~=3.0.5, preventing upgrades to jupyter-bokeh 4.x in notebook images that include TrustyAI. This requires either waiting for TrustyAI to update their dependency or excluding TrustyAI from jupyter-bokeh upgrades.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatahub-io/notebooks. They run `pipenv lock` inside UBI9 containers with specific platform arguments (`--platform=linux/amd64 --python-version 3.12`) to avoid host OS dependency conflicts when generating Pipfile.lock files.
jupyter/datascience/ubi9-python-3.11/requirements.txt (7)
undefined
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: The jupyter-bokeh pinning to 3.0.5 in TrustyAI notebook image was not due to TrustyAI code compatibility issues, but because the trustyai package itself explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency, causing pip dependency resolution conflicts when trying to upgrade to jupyter-bokeh 4.x.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: In the opendatahub-io/notebooks repository, TensorFlow packages with extras = ["and-cuda"] can cause build conflicts on macOS due to platform-specific CUDA packages. When the Dockerfile installs CUDA system-wide, removing the extras and letting TensorFlow find CUDA at runtime resolves these conflicts.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/datascience/ubi9-python-3.11/Pipfile:34-36
Timestamp: 2025-06-28T14:13:27.890Z
Learning: In the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pattern: core jupyterlab package uses exact pinning (==) across all notebook images to ensure UI consistency, while JupyterLab extensions and all server components (jupyter-server, jupyter-server-proxy, jupyter-server-terminals) use compatible release (~=) pinning to allow automatic security updates and bug fixes while maintaining API compatibility.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI 0.6.1 (latest version as of June 2025) has a hard dependency constraint on jupyter-bokeh~=3.0.5, preventing upgrades to jupyter-bokeh 4.x in notebook images that include TrustyAI. This requires either waiting for TrustyAI to update their dependency or excluding TrustyAI from jupyter-bokeh upgrades.
</retrieved_learning>
jupyter/minimal/ubi9-python-3.11/requirements.txt (4)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: The jupyter-bokeh pinning to 3.0.5 in TrustyAI notebook image was not due to TrustyAI code compatibility issues, but because the trustyai package itself explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency, causing pip dependency resolution conflicts when trying to upgrade to jupyter-bokeh 4.x.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
jupyter/pytorch/ubi9-python-3.11/requirements.txt (6)
undefined
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: In the opendatahub-io/notebooks repository, TensorFlow packages with extras = ["and-cuda"] can cause build conflicts on macOS due to platform-specific CUDA packages. When the Dockerfile installs CUDA system-wide, removing the extras and letting TensorFlow find CUDA at runtime resolves these conflicts.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: The jupyter-bokeh pinning to 3.0.5 in TrustyAI notebook image was not due to TrustyAI code compatibility issues, but because the trustyai package itself explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency, causing pip dependency resolution conflicts when trying to upgrade to jupyter-bokeh 4.x.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
</retrieved_learning>
runtimes/tensorflow/ubi9-python-3.11/requirements.txt (5)
undefined
<retrieved_learning>
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: In the opendatahub-io/notebooks repository, TensorFlow packages with extras = ["and-cuda"] can cause build conflicts on macOS due to platform-specific CUDA packages. When the Dockerfile installs CUDA system-wide, removing the extras and letting TensorFlow find CUDA at runtime resolves these conflicts.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI 0.6.1 (latest version as of June 2025) has a hard dependency constraint on jupyter-bokeh~=3.0.5, preventing upgrades to jupyter-bokeh 4.x in notebook images that include TrustyAI. This requires either waiting for TrustyAI to update their dependency or excluding TrustyAI from jupyter-bokeh upgrades.
</retrieved_learning>
jupyter/rocm/pytorch/ubi9-python-3.11/requirements.txt (6)
undefined
<retrieved_learning>
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: In the opendatahub-io/notebooks repository, TensorFlow packages with extras = ["and-cuda"] can cause build conflicts on macOS due to platform-specific CUDA packages. When the Dockerfile installs CUDA system-wide, removing the extras and letting TensorFlow find CUDA at runtime resolves these conflicts.
</retrieved_learning>
<retrieved_learning>
Learnt from: jiridanek
PR: #1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: The jupyter-bokeh pinning to 3.0.5 in TrustyAI notebook image was not due to TrustyAI code compatibility issues, but because the trustyai package itself explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency, causing pip dependency resolution conflicts when trying to upgrade to jupyter-bokeh 4.x.
</retrieved_learning>
🪛 Checkov (3.2.334)
jupyter/rocm/pytorch/ubi9-python-3.12/kustomize/base/statefulset.yaml
[MEDIUM] 2-58: Containers should not run with allowPrivilegeEscalation
(CKV_K8S_20)
[MEDIUM] 2-58: Minimize the admission of root containers
(CKV_K8S_23)
⏰ Context from checks skipped due to timeout of 90000ms (13)
- GitHub Check: build (rocm-jupyter-pytorch-ubi9-python-3.11, 3.11, linux/amd64, false) / build
- GitHub Check: build (runtime-datascience-ubi9-python-3.11, 3.11, linux/amd64, false) / build
- GitHub Check: build (rocm-jupyter-tensorflow-ubi9-python-3.11, 3.11, linux/amd64, false) / build
- GitHub Check: build (runtime-cuda-tensorflow-ubi9-python-3.11, 3.11, linux/amd64, false) / build
- GitHub Check: build (cuda-jupyter-pytorch-ubi9-python-3.11, 3.11, linux/amd64, false) / build
- GitHub Check: build (jupyter-datascience-ubi9-python-3.11, 3.11, linux/amd64, false) / build
- GitHub Check: build (rocm-runtime-tensorflow-ubi9-python-3.11, 3.11, linux/amd64, false) / build
- GitHub Check: build (codeserver-ubi9-python-3.11, 3.11, linux/amd64, false) / build
- GitHub Check: build (jupyter-minimal-ubi9-python-3.11, 3.11, linux/amd64, false) / build
- GitHub Check: build (rocm-jupyter-minimal-ubi9-python-3.11, 3.11, linux/amd64, false) / build
- GitHub Check: build (cuda-jupyter-minimal-ubi9-python-3.11, 3.11, linux/amd64, false) / build
- GitHub Check: build (runtime-cuda-pytorch-ubi9-python-3.11, 3.11, linux/amd64, false) / build
- GitHub Check: build (rocm-runtime-pytorch-ubi9-python-3.11, 3.11, linux/amd64, false) / build
🔇 Additional comments (5)
jupyter/rocm/pytorch/ubi9-python-3.12/kustomize/base/service.yaml (1)
8-15: Check label / selector coherence with StatefulSet afternamePrefixis applied
selector.app: notebookmust match the post-kustomize pod labels. If the template instatefulset.yamlstays empty whilenamePrefix& label transformers run, the final label set might diverge (e.g.app: jupyter-rocm-…). That breaks traffic routing and readiness probes.
Please runkustomize build(or the CI job) and inspect thatmetadata.labels.app == spec.selector.matchLabels.app == pod template.metadata.labels.appfor both Service and StatefulSet.
jupyter/rocm/pytorch/ubi9-python-3.12/Pipfile (1)
16-20: Verify the existence of wheel artifacts for PyTorch 2.6.0 + ROCm 6.2.4
At the time of writing, upstream often lags ROCm wheels behind trunk. Ensure the custom index actually contains the exact versions; otherwise the build will fail.If wheels are not yet published, pin to the latest available combo or build from source in the Dockerfile.
jupyter/rocm/pytorch/ubi9-python-3.12/Dockerfile.rocm (2)
143-151: LGTM: Well-structured image metadata.The label definitions follow container best practices with comprehensive metadata including source location, build information, and display names.
155-176: LGTM: Comprehensive PyTorch environment setup.The build process properly installs dependencies, configures Jupyter, applies customizations, and handles ROCm library de-vendoring. The permission fixes ensure OpenShift compatibility.
jupyter/rocm/pytorch/ubi9-python-3.12/test/test_notebook.ipynb (1)
142-154: LGTM: TensorBoard integration test covers essential functionality.The test properly validates TensorBoard writer creation and usage with image logging, which is essential for the PyTorch environment.
| aiohttp-cors==0.8.1; python_version >= '3.9' \ | ||
| --hash=sha256:3180cf304c5c712d626b9162b195b1db7ddf976a2a25172b35bb2448b890a80d \ | ||
| --hash=sha256:ccacf9cb84b64939ea15f859a146af1f662a6b1d68175754a07315e305fb1403 | ||
| >>>>>>> 6cd9ddb8dfc226e673fb229d12238159900806ef |
There was a problem hiding this comment.
Unresolved merge-conflict marker will break installation
Line 100 still contains a >>>>>>> <sha> marker. pip will choke on this invalid requirement spec and abort the build, blocking image creation.
->>>>>>> 6cd9ddb8dfc226e673fb229d12238159900806efDelete the marker (and any matching <<<<<<</======= siblings, if present in other files) and re-generate the lock/requirements files.
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In runtimes/datascience/ubi9-python-3.11/requirements.txt around lines 97 to
100, there is an unresolved merge conflict marker `>>>>>>>
6cd9ddb8dfc226e673fb229d12238159900806ef` that will cause pip installation to
fail. Remove this conflict marker and any related `<<<<<<<` or `=======` markers
if present, then regenerate the lock or requirements files to ensure a clean,
valid requirements specification.
| aiohttp-cors==0.8.1; python_version >= '3.9' \ | ||
| --hash=sha256:3180cf304c5c712d626b9162b195b1db7ddf976a2a25172b35bb2448b890a80d \ | ||
| --hash=sha256:ccacf9cb84b64939ea15f859a146af1f662a6b1d68175754a07315e305fb1403 | ||
| >>>>>>> 6cd9ddb8dfc226e673fb229d12238159900806ef | ||
| aiosignal==1.3.2; python_version >= '3.9' \ |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Remove leftover merge-conflict marker – it breaks pip install.
The >>>>>>> 6cd9ddb8dfc226e673fb229d12238159900806ef line is an unresolved merge-conflict artefact. pip will choke on it and abort the build of every ROCm PyTorch image derived from this requirements file.
->>>>>>> 6cd9ddb8dfc226e673fb229d12238159900806efDelete the line, push, and rebuild the image.
🏁 Script executed:
#!/bin/bash
# Scan the repo for any additional conflict markers.
rg --line-number --fixed-strings -e '<<<<<<<' -e '=======' -e '>>>>>>>'Length of output: 5248
Remove all leftover merge-conflict markers across the repo
Our scan surfaced unresolved conflict markers (<<<<<<<, =======, >>>>>>>) in multiple requirements.txt and Pipfile.lock files, which will break pip install and image builds. Please delete every line containing these markers and verify that no conflicts remain.
Key locations needing cleanup:
- runtimes/rocm-pytorch/ubi9-python-3.11/requirements.txt: line 104
- runtimes/rocm-tensorflow/ubi9-python-3.11/requirements.txt: lines 697–701 and 103
- codeserver/ubi9-python-3.11/requirements.txt: lines 11–25, 283, 597–673
- Various
Pipfile.lockfiles underjupyter/andruntimes/(e.g. lines 1212–1224 injupyter/rocm/tensorflow/ubi9-python-3.11/Pipfile.lock)
Example diff (remove all these kinds of lines):
- >>>>>>> 6cd9ddb8dfc226e673fb229d12238159900806efAfter cleanup, run:
rg --fixed-strings -e '<<<<<<<' -e '=======' -e '>>>>>>>'to confirm there are zero results, then rebuild the images to ensure all requirements parse correctly.
🤖 Prompt for AI Agents
In runtimes/rocm-pytorch/ubi9-python-3.11/requirements.txt around line 104,
remove all merge conflict markers such as <<<<<<<, =======, and >>>>>>>. Ensure
to delete the entire lines containing these markers and verify no other conflict
markers remain in this file or other specified files. After cleanup, run a
search for these markers across the repo to confirm none remain and rebuild the
images to validate requirements parsing.
| aiohttp-cors==0.8.1; python_version >= '3.9' \ | ||
| --hash=sha256:3180cf304c5c712d626b9162b195b1db7ddf976a2a25172b35bb2448b890a80d \ | ||
| --hash=sha256:ccacf9cb84b64939ea15f859a146af1f662a6b1d68175754a07315e305fb1403 | ||
| >>>>>>> 6cd9ddb8dfc226e673fb229d12238159900806ef |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Remove unresolved Git conflict marker – breaks pip install.
Line 104 still contains a merge-conflict terminator. Any pip install -r will fail because this line is not a valid requirement spec.
->>>>>>> 6cd9ddb8dfc226e673fb229d12238159900806efDelete the line and re-run sync-requirements-txt.sh so the lockfile hashes remain intact.
🏁 Script executed:
#!/usr/bin/env bash
# Find any leftover conflict markers across the repo
rg -n $'^(<<<<<<<|=======|>>>>>>>)' --color=alwaysLength of output: 7980
Remove all Git conflict markers in requirements and lockfiles – pip install will fail
The search revealed leftover conflict markers (<<<<<<<, =======, >>>>>>> 6cd9ddb8dfc226e673fb229d12238159900806ef) across multiple files. You must delete all of these marker lines and regenerate the synced requirement files and lockfiles.
Key locations (not exhaustive) include:
- runtimes/rocm-pytorch/ubi9-python-3.11/requirements.txt: line 104
- runtimes/pytorch/ubi9-python-3.11/requirements.txt: line 104
- runtimes/tensorflow/ubi9-python-3.11/requirements.txt: line 103
- runtimes/*/ubi9-python-3.11/Pipfile.lock: lines 139, 907–919 (and similar blocks)
- jupyter/*/ubi9-python-3.11/requirements.txt and Pipfile.lock: numerous conflict blocks
- codeserver/ubi9-python-3.11/requirements.txt and Pipfile.lock: conflict markers at the top and elsewhere
Action items:
- Remove every line starting with
<<<<<<<,=======, or>>>>>>> 6cd9ddb8dfc226e673fb229d12238159900806efin all affected files. - Re-run
sync-requirements-txt.sh(and, where applicable,pipenv lock --requirements) for each runtime and image variant to restore valid hashes and dependency specs.
This will ensure all requirements.txt and lockfiles are clean and installable.
🤖 Prompt for AI Agents
In runtimes/pytorch/ubi9-python-3.11/requirements.txt around line 104, remove
all Git conflict markers such as <<<<<<<, =======, and >>>>>>>
6cd9ddb8dfc226e673fb229d12238159900806ef. After cleaning these markers from this
and all other affected requirements and lockfiles, rerun the
sync-requirements-txt.sh script and pipenv lock --requirements where applicable
to regenerate valid hashes and dependency specifications, ensuring the files are
clean and pip install will succeed.
| platformdirs==4.3.6; python_version >= '3.8' \ | ||
| --hash=sha256:357fb2acbc885b0419afd3ce3ed34564c13c9b95c89360cd9563f73aa5e2b907 \ | ||
| --hash=sha256:73e575e1408ab8103900836b97580d5307456908a03e92031bab39e4554cc3fb | ||
| ======= |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Duplicate platformdirs entry after conflict merge
Even after resolving markers, ensure only one platformdirs line is present.
Having both 4.3.6 and 4.3.8 will cause pip resolution conflicts.
Run the sync script again or grep for duplicates:
Expect exactly one line in the final file.
Also applies to: 756-759
🏁 Script executed:
#!/bin/bash
grep -n '^platformdirs==' codeserver/ubi9-python-3.11/requirements.txtLength of output: 174
Remove duplicate platformdirs entries
There are two conflicting entries for platformdirs in codeserver/ubi9-python-3.11/requirements.txt. Please keep exactly one, for example the newer 4.3.8 line, and remove the older 4.3.6 entry:
• Line 670–673 (platformdirs==4.3.6; python_version >= '3.8')
• Line 756–759 (platformdirs==4.3.8; python_version >= '3.9')
Suggested change (keep 4.3.8):
--- a/codeserver/ubi9-python-3.11/requirements.txt
+++ b/codeserver/ubi9-python-3.11/requirements.txt
@@ -667,8 +667,6 @@
platformdirs==4.3.6; python_version >= '3.8' \
- --hash=sha256:357fb2acbc885b0419afd3ce3ed34564c13c9b95c89360cd9563f73aa5e2b907 \
- --hash=sha256:73e575e1408ab8103900836b97580d5307456908a03e92031bab39e4554cc3fb
=======Remove lines 670–673 entirely so only the 4.3.8 entry remains.
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In codeserver/ubi9-python-3.11/requirements.txt at lines 670 to 673, there is a
duplicate entry for platformdirs version 4.3.6 that conflicts with a newer
version 4.3.8 listed at lines 756 to 759. Remove the entire block from lines 670
to 673 to keep only the newer platformdirs==4.3.8 entry and avoid version
conflicts.
| <<<<<<< HEAD | ||
| boto3==1.37.15; python_version >= '3.8' \ | ||
| --hash=sha256:586332456fff19328d57a88214a2ac2eda1bafab743556a836eda46a4ce613c6 \ | ||
| --hash=sha256:78cc1b483cc637e1df8e81498d66f89550d4ee92175ccab5be1a2226672fe6b9 | ||
| botocore==1.37.15; python_version >= '3.8' \ | ||
| --hash=sha256:72e6f1db6ebc4112d6ba719c97ad71ac7cf4a2f3729ae74fa225641e3ddcba92 \ | ||
| --hash=sha256:996b8d6a342ad7735eb07d8b4a81dad86e60ce0889ccb3edec0cd66eece85393 | ||
| ======= | ||
| boto3==1.37.38; python_version >= '3.8' \ | ||
| --hash=sha256:88c02910933ab7777597d1ca7c62375f52822e0aa1a8e0c51b2598a547af42b2 \ | ||
| --hash=sha256:b6d42803607148804dff82389757827a24ce9271f0583748853934c86310999f | ||
| botocore==1.37.38; python_version >= '3.8' \ | ||
| --hash=sha256:23b4097780e156a4dcaadfc1ed156ce25cb95b6087d010c4bb7f7f5d9bc9d219 \ | ||
| --hash=sha256:c3ea386177171f2259b284db6afc971c959ec103fa2115911c4368bea7cbbc5d | ||
| >>>>>>> 6cd9ddb8dfc226e673fb229d12238159900806ef |
There was a problem hiding this comment.
Unresolved merge-conflict markers make the file syntactically invalid
<<<<<<< HEAD, =======, and >>>>>>> … are still present.
pip install -r requirements.txt will choke on these lines and the build will fail.
-<<<<<<< HEAD
-boto3==1.37.15 …
-botocore==1.37.15 …
-=======
+boto3==1.37.38 … # keep ONE coherent block (or regenerate via sync script)
+botocore==1.37.38 …
->>>>>>> 6cd9ddb8dfc226e673fb229d12238159900806efRemove the markers and pick one version of each package (prefer the newer set, or simply rerun /scripts/sync-requirements-txt.sh to regenerate a clean file).
Failing to do so will break every container/image that consumes this requirements file.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <<<<<<< HEAD | |
| boto3==1.37.15; python_version >= '3.8' \ | |
| --hash=sha256:586332456fff19328d57a88214a2ac2eda1bafab743556a836eda46a4ce613c6 \ | |
| --hash=sha256:78cc1b483cc637e1df8e81498d66f89550d4ee92175ccab5be1a2226672fe6b9 | |
| botocore==1.37.15; python_version >= '3.8' \ | |
| --hash=sha256:72e6f1db6ebc4112d6ba719c97ad71ac7cf4a2f3729ae74fa225641e3ddcba92 \ | |
| --hash=sha256:996b8d6a342ad7735eb07d8b4a81dad86e60ce0889ccb3edec0cd66eece85393 | |
| ======= | |
| boto3==1.37.38; python_version >= '3.8' \ | |
| --hash=sha256:88c02910933ab7777597d1ca7c62375f52822e0aa1a8e0c51b2598a547af42b2 \ | |
| --hash=sha256:b6d42803607148804dff82389757827a24ce9271f0583748853934c86310999f | |
| botocore==1.37.38; python_version >= '3.8' \ | |
| --hash=sha256:23b4097780e156a4dcaadfc1ed156ce25cb95b6087d010c4bb7f7f5d9bc9d219 \ | |
| --hash=sha256:c3ea386177171f2259b284db6afc971c959ec103fa2115911c4368bea7cbbc5d | |
| >>>>>>> 6cd9ddb8dfc226e673fb229d12238159900806ef | |
| # codeserver/ubi9-python-3.11/requirements.txt (lines 11–25) | |
| boto3==1.37.38; python_version >= '3.8' \ | |
| --hash=sha256:88c02910933ab7777597d1ca7c62375f52822e0aa1a8e0c51b2598a547af42b2 \ | |
| --hash=sha256:b6d42803607148804dff82389757827a24ce9271f0583748853934c86310999f | |
| botocore==1.37.38; python_version >= '3.8' \ | |
| --hash=sha256:23b4097780e156a4dcaadfc1ed156ce25cb95b6087d010c4bb7f7f5d9bc9d219 \ | |
| --hash=sha256:c3ea386177171f2259b284db6afc971c959ec103fa2115911c4368bea7cbbc5d |
🤖 Prompt for AI Agents
In codeserver/ubi9-python-3.11/requirements.txt between lines 11 and 25, there
are unresolved git merge conflict markers (<<<<<<< HEAD, =======, >>>>>>>) that
make the file invalid and cause pip install to fail. Remove all these conflict
markers and choose one consistent version of each package, preferably the newer
versions shown after the ======= marker. Alternatively, rerun the
/scripts/sync-requirements-txt.sh script to regenerate a clean requirements.txt
without conflicts.
| RUN echo "[ROCm]" > /etc/yum.repos.d/rocm.repo && \ | ||
| echo "name=ROCm" >> /etc/yum.repos.d/rocm.repo && \ | ||
| echo "baseurl=https://repo.radeon.com/rocm/rhel9/$ROCM_VERSION/main" >> /etc/yum.repos.d/rocm.repo && \ | ||
| echo "enabled=1" >> /etc/yum.repos.d/rocm.repo && \ | ||
| echo "gpgcheck=0" >> /etc/yum.repos.d/rocm.repo && \ | ||
| echo "[amdgpu]" > /etc/yum.repos.d/amdgpu.repo && \ | ||
| echo "name=amdgpu" >> /etc/yum.repos.d/amdgpu.repo && \ | ||
| echo "baseurl=https://repo.radeon.com/amdgpu/$AMDGPU_VERSION/rhel/9.4/main/x86_64" >> /etc/yum.repos.d/amdgpu.repo && \ | ||
| echo "enabled=1" >> /etc/yum.repos.d/amdgpu.repo && \ | ||
| echo "gpgcheck=0" >> /etc/yum.repos.d/amdgpu.repo && \ | ||
| yum install -y rocm-developer-tools rocm-ml-sdk rocm-opencl-sdk rocm-openmp-sdk rocm-utils && \ | ||
| yum clean all && rm -rf /var/cache/yum |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Security: Disabled GPG verification for ROCm repositories.
The ROCm and AMDGPU repositories are configured with gpgcheck=0, which disables package signature verification and creates a security vulnerability.
Consider enabling GPG checking if keys are available, or document the security tradeoff:
- echo "gpgcheck=0" >> /etc/yum.repos.d/rocm.repo && \
+ echo "gpgcheck=1" >> /etc/yum.repos.d/rocm.repo && \
+ echo "gpgkey=https://repo.radeon.com/rocm/rocm.gpg.key" >> /etc/yum.repos.d/rocm.repo && \
[...similar for amdgpu repo...]Verify if AMD provides GPG keys for their repositories:
🌐 Web query:
Does AMD provide GPG keys for ROCm and AMDGPU yum repositories for package signature verification?
💡 Result:
Yes, AMD does provide GPG keys for both the ROCm and AMDGPU yum repositories to enable package signature verification.
When configuring the ROCm or AMDGPU repositories on RHEL, CentOS, or compatible systems using yum or dnf, the standard repository configuration includes the gpgcheck=1 setting along with a gpgkey field pointing to AMD's public signing key. This ensures that both repository metadata and RPM packages are verified for authenticity and integrity before installation.
Key details:
-
The GPG public key used for signature verification is hosted by AMD at:
**https://repo.radeon.com/rocm/rocm.gpg.key**[1][2][4]. -
Example snippet for a
.repofile (as provided in AMD's official ROCm documentation):[amdgpu] name=amdgpu baseurl=https://repo.radeon.com/amdgpu/6.1.1/rhel/9.4/main/x86_64/ enabled=1 priority=50 gpgcheck=1 gpgkey=https://repo.radeon.com/rocm/rocm.gpg.key
-
The same GPG key is used for both ROCm and AMDGPU repositories across supported RHEL and CentOS versions[2][4].
-
Upon first installation, you may be prompted to import the GPG key (for example, with key ID
1A693C5C), which can also be found in the installer location after extracting or installing the driver RPMs (e.g.,/etc/amdgpu-install/rocm.gpg.key)[5]. -
This key is used to verify the digital signatures of the repository metadata and distributed packages, helping prevent tampering or unauthorized modifications[2][5].
In summary:
AMD provides and publicly hosts GPG keys to secure the ROCm and AMDGPU yum repositories, and you are strongly encouraged to include gpgcheck=1 and specify the key location in your repository configuration for proper package signature verification[1][2][4][5].
Citations:
- 1: https://discussion.fedoraproject.org/t/how-to-deal-with-amds-new-amdgpu-installer-20-40/59499/16
- 2: https://rocm.docs.amd.com/projects/install-on-linux/en/docs-6.1.1/how-to/native-install/rhel.html
- 3: https://help.sonatype.com/en/gpg-signatures-for-yum-proxy-group.html
- 4: https://rocm.docs.amd.com/projects/install-on-linux/en/docs-6.2.4/install/native-install/multi-version-install.html
- 5: https://community.amd.com/t5/pc-drivers-software/nokey-provided-with-rhel-9-rpm/td-p/526880
- 6: [Issue]: EL9.4 ROCM 6.3 repo installation results in amd-smi-lib RPM and python errors ROCm/ROCm#4130
- 7: Warning with deprecated apt-key add and not using trusted.gpg.d ROCm/ROCm#1869
- 8: https://discussion.fedoraproject.org/t/how-to-deal-with-amds-new-amdgpu-installer-20-40/59499
- 9: RHEL (AlmaLinux) 9.1 + 6700M ROCm 5.4.1 display driver not working ROCm/ROCm#1884
- 10: GPG issue on ubuntu ROCm/ROCm#2362
Enable GPG verification for ROCm and AMDGPU repositories
AMD publishes a public GPG key to validate both ROCm and AMDGPU yum repos. Please update your repository definitions to turn on signature checks and reference the key:
• File: jupyter/rocm/pytorch/ubi9-python-3.12/Dockerfile.rocm
• Lines: 56–67
Suggested diff:
RUN echo "[ROCm]" > /etc/yum.repos.d/rocm.repo && \
echo "name=ROCm" >> /etc/yum.repos.d/rocm.repo && \
- echo "baseurl=https://repo.radeon.com/rocm/rhel9/$ROCM_VERSION/main" >> /etc/yum.repos.d/rocm.repo && \
+ echo "baseurl=https://repo.radeon.com/rocm/rhel9/$ROCM_VERSION/main" >> /etc/yum.repos.d/rocm.repo && \
echo "enabled=1" >> /etc/yum.repos.d/rocm.repo && \
- echo "gpgcheck=0" >> /etc/yum.repos.d/rocm.repo && \
+ echo "gpgcheck=1" >> /etc/yum.repos.d/rocm.repo && \
+ echo "gpgkey=https://repo.radeon.com/rocm/rocm.gpg.key" >> /etc/yum.repos.d/rocm.repo && \
echo "[amdgpu]" > /etc/yum.repos.d/amdgpu.repo && \
echo "name=amdgpu" >> /etc/yum.repos.d/amdgpu.repo && \
- echo "baseurl=https://repo.radeon.com/amdgpu/$AMDGPU_VERSION/rhel/9.4/main/x86_64" >> /etc/yum.repos.d/amdgpu.repo && \
+ echo "baseurl=https://repo.radeon.com/amdgpu/$AMDGPU_VERSION/rhel/9.4/main/x86_64" >> /etc/yum.repos.d/amdgpu.repo && \
echo "enabled=1" >> /etc/yum.repos.d/amdgpu.repo && \
- echo "gpgcheck=0" >> /etc/yum.repos.d/amdgpu.repo && \
+ echo "gpgcheck=1" >> /etc/yum.repos.d/amdgpu.repo && \
+ echo "gpgkey=https://repo.radeon.com/rocm/rocm.gpg.key" >> /etc/yum.repos.d/amdgpu.repo && \
yum install -y rocm-developer-tools rocm-ml-sdk rocm-opencl-sdk rocm-openmp-sdk rocm-utils && \
yum clean all && rm -rf /var/cache/yumThis ensures packages are verified using AMD’s published key: https://repo.radeon.com/rocm/rocm.gpg.key.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| RUN echo "[ROCm]" > /etc/yum.repos.d/rocm.repo && \ | |
| echo "name=ROCm" >> /etc/yum.repos.d/rocm.repo && \ | |
| echo "baseurl=https://repo.radeon.com/rocm/rhel9/$ROCM_VERSION/main" >> /etc/yum.repos.d/rocm.repo && \ | |
| echo "enabled=1" >> /etc/yum.repos.d/rocm.repo && \ | |
| echo "gpgcheck=0" >> /etc/yum.repos.d/rocm.repo && \ | |
| echo "[amdgpu]" > /etc/yum.repos.d/amdgpu.repo && \ | |
| echo "name=amdgpu" >> /etc/yum.repos.d/amdgpu.repo && \ | |
| echo "baseurl=https://repo.radeon.com/amdgpu/$AMDGPU_VERSION/rhel/9.4/main/x86_64" >> /etc/yum.repos.d/amdgpu.repo && \ | |
| echo "enabled=1" >> /etc/yum.repos.d/amdgpu.repo && \ | |
| echo "gpgcheck=0" >> /etc/yum.repos.d/amdgpu.repo && \ | |
| yum install -y rocm-developer-tools rocm-ml-sdk rocm-opencl-sdk rocm-openmp-sdk rocm-utils && \ | |
| yum clean all && rm -rf /var/cache/yum | |
| RUN echo "[ROCm]" > /etc/yum.repos.d/rocm.repo && \ | |
| echo "name=ROCm" >> /etc/yum.repos.d/rocm.repo && \ | |
| echo "baseurl=https://repo.radeon.com/rocm/rhel9/$ROCM_VERSION/main" >> /etc/yum.repos.d/rocm.repo && \ | |
| echo "enabled=1" >> /etc/yum.repos.d/rocm.repo && \ | |
| echo "gpgcheck=1" >> /etc/yum.repos.d/rocm.repo && \ | |
| echo "gpgkey=https://repo.radeon.com/rocm/rocm.gpg.key" >> /etc/yum.repos.d/rocm.repo && \ | |
| echo "[amdgpu]" > /etc/yum.repos.d/amdgpu.repo && \ | |
| echo "name=amdgpu" >> /etc/yum.repos.d/amdgpu.repo && \ | |
| echo "baseurl=https://repo.radeon.com/amdgpu/$AMDGPU_VERSION/rhel/9.4/main/x86_64" >> /etc/yum.repos.d/amdgpu.repo && \ | |
| echo "enabled=1" >> /etc/yum.repos.d/amdgpu.repo && \ | |
| echo "gpgcheck=1" >> /etc/yum.repos.d/amdgpu.repo && \ | |
| echo "gpgkey=https://repo.radeon.com/rocm/rocm.gpg.key" >> /etc/yum.repos.d/amdgpu.repo && \ | |
| yum install -y rocm-developer-tools rocm-ml-sdk rocm-opencl-sdk rocm-openmp-sdk rocm-utils && \ | |
| yum clean all && rm -rf /var/cache/yum |
🤖 Prompt for AI Agents
In jupyter/rocm/pytorch/ubi9-python-3.12/Dockerfile.rocm lines 56 to 67, the yum
repository definitions for ROCm and AMDGPU have gpgcheck disabled, which skips
package signature verification. To fix this, enable gpgcheck by setting
"gpgcheck=1" in both repo files and add a "gpgkey" line pointing to
"https://repo.radeon.com/rocm/rocm.gpg.key" to ensure packages are verified
using AMD's public GPG key.
| RUN curl -Lo mongodb-cli-mongocli-v${MONGOCLI_VERSION}.zip https://github.com/mongodb/mongodb-cli/archive/refs/tags/mongocli/v${MONGOCLI_VERSION}.zip | ||
| RUN unzip ./mongodb-cli-mongocli-v${MONGOCLI_VERSION}.zip | ||
| RUN cd ./mongodb-cli-mongocli-v${MONGOCLI_VERSION}/ && \ | ||
| CGO_ENABLED=1 GOOS=linux go build -a -tags strictfipsruntime -o /tmp/mongocli ./cmd/mongocli/ |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Security: Verify downloaded archive integrity.
The MongoDB CLI source is downloaded without checksum verification, creating a potential security risk.
Please verify that the downloaded archive matches expected checksums or consider implementing checksum validation:
🏁 Script executed:
#!/bin/bash
# Description: Check if MongoDB CLI releases provide checksums for verification
# Check MongoDB CLI releases for available checksums
curl -s "https://api.github.com/repos/mongodb/mongodb-cli/releases/tags/mongocli/v2.0.3" | jq '.assets[] | select(.name | contains("checksum") or contains("sha")) | .name'Length of output: 207
Add checksum verification for MongoDB CLI download
We’ve confirmed the MongoDB CLI release includes both checksums.txt and checksums.txt.sig. To harden supply-chain security, fetch and verify the checksum (and optionally its signature) immediately after downloading the archive.
• File: jupyter/rocm/pytorch/ubi9-python-3.12/Dockerfile.rocm
• Insert after the curl -Lo mongodb-cli-mongocli-v${MONGOCLI_VERSION}.zip … step:
RUN curl -Lo mongodb-cli-mongocli-v${MONGOCLI_VERSION}.zip \
https://github.com/mongodb/mongodb-cli/archive/refs/tags/mongocli/v${MONGOCLI_VERSION}.zip
+ RUN curl -Lo checksums.txt \
+ https://github.com/mongodb/mongodb-cli/releases/download/mongocli/v${MONGOCLI_VERSION}/checksums.txt && \
+ grep mongodb-cli-mongocli-v${MONGOCLI_VERSION}.zip checksums.txt | sha256sum -c -
RUN unzip ./mongodb-cli-mongocli-v${MONGOCLI_VERSION}.zipOptionally, if you want signature validation as well:
+ RUN curl -Lo checksums.txt.sig \
+ https://github.com/mongodb/mongodb-cli/releases/download/mongocli/v${MONGOCLI_VERSION}/checksums.txt.sig && \
+ gpg --batch --keyserver hkps://keys.openpgp.org --verify checksums.txt.sig checksums.txt🤖 Prompt for AI Agents
In jupyter/rocm/pytorch/ubi9-python-3.12/Dockerfile.rocm around lines 9 to 12,
the MongoDB CLI zip download lacks checksum verification, which is important for
supply-chain security. After downloading the zip file with curl, add steps to
also download the corresponding checksums.txt and checksums.txt.sig files, then
verify the checksum of the downloaded zip against the checksums.txt file.
Optionally, verify the signature of checksums.txt.sig using the appropriate
public key before checksum validation. This ensures the integrity and
authenticity of the downloaded archive before proceeding with unzip and build
steps.
| "def load_expected_versions() -> dict:\n", | ||
| " lock_file = Path('./expected_versions.json')\n", | ||
| " data = {}\n", | ||
| "\n", | ||
| " with open(lock_file, 'r') as file:\n", | ||
| " data = json.load(file)\n", | ||
| "\n", | ||
| " return data \n", |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add file existence check for expected_versions.json.
The function assumes the expected_versions.json file exists without validation, which could cause a runtime error during testing.
def load_expected_versions() -> dict:
lock_file = Path('./expected_versions.json')
+ if not lock_file.exists():
+ raise FileNotFoundError(f"Expected versions file not found: {lock_file}")
data = {}
with open(lock_file, 'r') as file:
data = json.load(file)
return data📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "def load_expected_versions() -> dict:\n", | |
| " lock_file = Path('./expected_versions.json')\n", | |
| " data = {}\n", | |
| "\n", | |
| " with open(lock_file, 'r') as file:\n", | |
| " data = json.load(file)\n", | |
| "\n", | |
| " return data \n", | |
| def load_expected_versions() -> dict: | |
| lock_file = Path('./expected_versions.json') | |
| if not lock_file.exists(): | |
| raise FileNotFoundError(f"Expected versions file not found: {lock_file}") | |
| data = {} | |
| with open(lock_file, 'r') as file: | |
| data = json.load(file) | |
| return data |
🤖 Prompt for AI Agents
In jupyter/rocm/pytorch/ubi9-python-3.12/test/test_notebook.ipynb around lines
26 to 33, the function load_expected_versions assumes the file
expected_versions.json exists, which may cause a runtime error if it does not.
Add a check to verify the file's existence before opening it. If the file does
not exist, handle this case gracefully by returning an empty dictionary or
raising a clear error message.
| " # Load a pre-trained PyTorch model (for example, ResNet-18)\n", | ||
| " model = models.resnet18(pretrained=True)\n", | ||
| " model.eval()\n", |
There was a problem hiding this comment.
Update deprecated pretrained parameter.
The pretrained=True parameter is deprecated in recent PyTorch versions and should be replaced with weights parameter.
- model = models.resnet18(pretrained=True)
+ model = models.resnet18(weights=models.ResNet18_Weights.IMAGENET1K_V1)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| " # Load a pre-trained PyTorch model (for example, ResNet-18)\n", | |
| " model = models.resnet18(pretrained=True)\n", | |
| " model.eval()\n", | |
| # Load a pre-trained PyTorch model (for example, ResNet-18) | |
| model = models.resnet18(weights=models.ResNet18_Weights.IMAGENET1K_V1) | |
| model.eval() |
🤖 Prompt for AI Agents
In jupyter/rocm/pytorch/ubi9-python-3.12/test/test_notebook.ipynb around lines
157 to 159, replace the deprecated pretrained=True argument in the
models.resnet18() call with the new weights parameter. Use the appropriate
weights enum from torchvision.models to specify pretrained weights, for example,
weights=torchvision.models.ResNet18_Weights.DEFAULT, to update the code to the
current PyTorch API.
| " def test_polynomial_fitting(self):\n", | ||
| " dtype = torch.float\n", | ||
| " device = torch.device(\"cpu\")\n", | ||
| " # device = torch.device(\"cuda:0\") # Uncomment this to run on GPU\n", | ||
| "\n", | ||
| " # Create random input and output data\n", | ||
| " x = torch.linspace(-math.pi, math.pi, 2000, device=device, dtype=dtype)\n", | ||
| " y = torch.sin(x)\n", | ||
| "\n", | ||
| " # Randomly initialize weights\n", | ||
| " a = torch.randn((), device=device, dtype=dtype)\n", | ||
| " b = torch.randn((), device=device, dtype=dtype)\n", | ||
| " c = torch.randn((), device=device, dtype=dtype)\n", | ||
| " d = torch.randn((), device=device, dtype=dtype)\n", | ||
| "\n", | ||
| " learning_rate = 1e-6\n", | ||
| " for t in range(2000):\n", | ||
| " # Forward pass: compute predicted y\n", | ||
| " y_pred = a + b * x + c * x ** 2 + d * x ** 3\n", | ||
| "\n", | ||
| " # Compute and print loss\n", | ||
| " loss = (y_pred - y).pow(2).sum().item()\n", | ||
| " if t % 100 == 99:\n", | ||
| " print(t, loss)\n", | ||
| "\n", | ||
| " # Backprop to compute gradients of a, b, c, d with respect to loss\n", | ||
| " grad_y_pred = 2.0 * (y_pred - y)\n", | ||
| " grad_a = grad_y_pred.sum()\n", | ||
| " grad_b = (grad_y_pred * x).sum()\n", | ||
| " grad_c = (grad_y_pred * x ** 2).sum()\n", | ||
| " grad_d = (grad_y_pred * x ** 3).sum()\n", | ||
| "\n", | ||
| " # Update weights using gradient descent\n", | ||
| " a -= learning_rate * grad_a\n", | ||
| " b -= learning_rate * grad_b\n", | ||
| " c -= learning_rate * grad_c\n", | ||
| " d -= learning_rate * grad_d\n", | ||
| "\n", | ||
| "\n", | ||
| " print(f'Result: y = {a.item()} + {b.item()} x + {c.item()} x^2 + {d.item()} x^3')\n", |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add assertions to polynomial fitting test.
This test performs a complete polynomial fitting operation but lacks assertions to verify the results, making it more of a demo than a test.
print(f'Result: y = {a.item()} + {b.item()} x + {c.item()} x^2 + {d.item()} x^3')
+
+ # Assert that the fitting converged to reasonable values
+ self.assertLess(loss, 100, "Polynomial fitting did not converge properly")
+ # Assert that coefficients are reasonable for sin(x) approximation
+ self.assertAlmostEqual(a.item(), 0, delta=0.1, msg="Constant term should be near 0")
+ self.assertAlmostEqual(b.item(), 1, delta=0.1, msg="Linear term should be near 1")📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| " def test_polynomial_fitting(self):\n", | |
| " dtype = torch.float\n", | |
| " device = torch.device(\"cpu\")\n", | |
| " # device = torch.device(\"cuda:0\") # Uncomment this to run on GPU\n", | |
| "\n", | |
| " # Create random input and output data\n", | |
| " x = torch.linspace(-math.pi, math.pi, 2000, device=device, dtype=dtype)\n", | |
| " y = torch.sin(x)\n", | |
| "\n", | |
| " # Randomly initialize weights\n", | |
| " a = torch.randn((), device=device, dtype=dtype)\n", | |
| " b = torch.randn((), device=device, dtype=dtype)\n", | |
| " c = torch.randn((), device=device, dtype=dtype)\n", | |
| " d = torch.randn((), device=device, dtype=dtype)\n", | |
| "\n", | |
| " learning_rate = 1e-6\n", | |
| " for t in range(2000):\n", | |
| " # Forward pass: compute predicted y\n", | |
| " y_pred = a + b * x + c * x ** 2 + d * x ** 3\n", | |
| "\n", | |
| " # Compute and print loss\n", | |
| " loss = (y_pred - y).pow(2).sum().item()\n", | |
| " if t % 100 == 99:\n", | |
| " print(t, loss)\n", | |
| "\n", | |
| " # Backprop to compute gradients of a, b, c, d with respect to loss\n", | |
| " grad_y_pred = 2.0 * (y_pred - y)\n", | |
| " grad_a = grad_y_pred.sum()\n", | |
| " grad_b = (grad_y_pred * x).sum()\n", | |
| " grad_c = (grad_y_pred * x ** 2).sum()\n", | |
| " grad_d = (grad_y_pred * x ** 3).sum()\n", | |
| "\n", | |
| " # Update weights using gradient descent\n", | |
| " a -= learning_rate * grad_a\n", | |
| " b -= learning_rate * grad_b\n", | |
| " c -= learning_rate * grad_c\n", | |
| " d -= learning_rate * grad_d\n", | |
| "\n", | |
| "\n", | |
| " print(f'Result: y = {a.item()} + {b.item()} x + {c.item()} x^2 + {d.item()} x^3')\n", | |
| def test_polynomial_fitting(self): | |
| dtype = torch.float | |
| device = torch.device("cpu") | |
| # device = torch.device("cuda:0") # Uncomment this to run on GPU | |
| # Create random input and output data | |
| x = torch.linspace(-math.pi, math.pi, 2000, device=device, dtype=dtype) | |
| y = torch.sin(x) | |
| # Randomly initialize weights | |
| a = torch.randn((), device=device, dtype=dtype) | |
| b = torch.randn((), device=device, dtype=dtype) | |
| c = torch.randn((), device=device, dtype=dtype) | |
| d = torch.randn((), device=device, dtype=dtype) | |
| learning_rate = 1e-6 | |
| for t in range(2000): | |
| # Forward pass: compute predicted y | |
| y_pred = a + b * x + c * x ** 2 + d * x ** 3 | |
| # Compute and print loss | |
| loss = (y_pred - y).pow(2).sum().item() | |
| if t % 100 == 99: | |
| print(t, loss) | |
| # Backprop to compute gradients of a, b, c, d with respect to loss | |
| grad_y_pred = 2.0 * (y_pred - y) | |
| grad_a = grad_y_pred.sum() | |
| grad_b = (grad_y_pred * x).sum() | |
| grad_c = (grad_y_pred * x ** 2).sum() | |
| grad_d = (grad_y_pred * x ** 3).sum() | |
| # Update weights using gradient descent | |
| a -= learning_rate * grad_a | |
| b -= learning_rate * grad_b | |
| c -= learning_rate * grad_c | |
| d -= learning_rate * grad_d | |
| print(f'Result: y = {a.item()} + {b.item()} x + {c.item()} x^2 + {d.item()} x^3') | |
| # Assert that the fitting converged to reasonable values | |
| self.assertLess(loss, 100, "Polynomial fitting did not converge properly") | |
| # Assert that coefficients are reasonable for sin(x) approximation | |
| self.assertAlmostEqual(a.item(), 0, delta=0.1, msg="Constant term should be near 0") | |
| self.assertAlmostEqual(b.item(), 1, delta=0.1, msg="Linear term should be near 1") |
🤖 Prompt for AI Agents
In jupyter/rocm/pytorch/ubi9-python-3.12/test/test_notebook.ipynb between lines
69 and 108, the polynomial fitting test lacks assertions to verify the
correctness of the fitted polynomial coefficients. Add assertions after the
training loop to check that the learned coefficients a, b, c, and d are close to
the expected values for the sine function approximation, using an appropriate
tolerance. This will convert the demo-like code into a proper test by validating
the fitting results.
|
@dibryant: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
Fixes for https://issues.redhat.com/browse/RHOAIENG-27435
Description
Create Rocm Pytorch Python 3.12
How Has This Been Tested?
$ make rocm-jupyter-pytorch-ubi9-python-3.12
-e RELEASE_PYTHON_VERSION=3.12
-e IMAGE_REGISTRY="quay.io/${YOUR_USER}/workbench-images"
-e RELEASE="2025b"
-e CONTAINER_BUILD_CACHE_ARGS=""
-e PUSH_IMAGES="no"
$ export QUAY_IMAGE=$(podman images --format "{{.Repository}}:{{.Tag}}" | head -1)
$ podman run -it -p 8888:8888 $QUAY_IMAGE
Merge criteria:
Summary by CodeRabbit
New Features
Bug Fixes
Chores