Skip to content

Add TeX Live and Pandoc installation for ppc64le #1179

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 12 commits into
base: main
Choose a base branch
from

Conversation

puneetsharma21
Copy link

@puneetsharma21 puneetsharma21 commented Jun 23, 2025

Description

This PR adds support for installing TeX Live and Pandoc in the Jupyter notebook image for the ppc64le (IBM Power) architecture to enable PDF export functionality.

Key Changes:

  • Added logic to install TeX Live in install_pdf_deps.sh with support for ppc64le.
  • Installed Pandoc for Power architecture using system package manager.
  • Updated Dockerfile.cpu to:
    • Set the appropriate TeX Live path for Power
    • Validate pdflatex availability post-install
  • Ensured existing x86_64 logic is not affected.

How Has This Been Tested?

  • Tested in a ppc64le container with the following validations:
  • Confirmed pdflatex --version executes successfully and returns expected output.
  • Confirmed pandoc --version is available in the image.
  • Built the full Docker image locally on a Power VM

Merge criteria:

  • The commits are squashed in a cohesive manner and have meaningful messages.
  • Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
  • The developer has manually tested the changes and verified that the changes work

Summary by CodeRabbit

  • New Features

    • Added support for exporting PDFs by including TeX Live and Pandoc in the environment, with installation tailored for both ppc64le and x86_64 architectures.
  • Chores

    • Improved image build process by introducing a multi-stage build for more efficient and maintainable installation of PDF export dependencies.

Copy link
Contributor

openshift-ci bot commented Jun 23, 2025

Hi @puneetsharma21. Thanks for your PR.

I'm waiting for a opendatahub-io member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

Copy link
Contributor

coderabbitai bot commented Jun 23, 2025

"""

Walkthrough

A multi-stage Docker build process was introduced for the Jupyter minimal image, adding a dedicated stage to build and install TeX Live and Pandoc using new architecture-aware shell scripts. The final image now copies these prebuilt binaries, and the environment is adjusted accordingly. Two new utility scripts for TeX Live and Pandoc installation were added.

Changes

Files / Paths Change Summary
jupyter/minimal/ubi9-python-3.11/Dockerfile.cpu, jupyter/minimal/ubi9-python-3.12/Dockerfile.cpu Refactored to use a multi-stage build; adds pdf-builder stage for TeX Live and Pandoc, removes old PDF deps script, updates PATH.
jupyter/utils/install_pandoc.sh, jupyter/utils/install_texlive.sh Added new architecture-aware shell scripts for installing Pandoc and TeX Live, supporting ppc64le and amd64 architectures.

Possibly related PRs

Suggested labels

lgtm, approved
"""


📜 Recent review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 510e5a0 and 6673212.

📒 Files selected for processing (1)
  • jupyter/utils/install_texlive.sh (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • jupyter/utils/install_texlive.sh
✨ Finishing Touches
  • 📝 Generate Docstrings

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need 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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

This comment was marked as outdated.

@openshift-ci openshift-ci bot added size/m and removed size/m labels Jun 24, 2025
@jiridanek
Copy link
Member

@coderabbitai review

Copy link
Contributor

coderabbitai bot commented Jun 24, 2025

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@openshift-ci openshift-ci bot added size/m and removed size/m labels Jun 24, 2025
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🧹 Nitpick comments (4)
jupyter/utils/install_pdf_deps.sh (3)

13-16: Hard-coded TeX Live 2025 URL is brittle

Pointing to a specific nightly snapshot (texlive-20250308-source.tar.xz) risks sudden 404s when mirrors rotate or prune historic files.
Expose the version as a variable and fall back to a mirror list or checksum verification so future rebuilds stay reproducible.


18-21: Temporary build toolchain inflates the final image

dnf install pulls a full compiler stack but it is never removed. Either:

  1. Perform the build in a separate stage and COPY --from only /opt/texlive/2025, or
  2. Remove RPMs and clean caches after make install.

Both cut the image size by hundreds of MB and reduce CVE surface.


31-36: Symlink & PATH export are not fully reliable

  • Use ln -sf to avoid failures on re-runs when the link already exists.
  • The export PATH=… line has no effect outside the script’s process during a RUN layer. Persisting is already handled in the Dockerfile, so the export can be removed to avoid confusion.
jupyter/minimal/ubi9-python-3.11/Dockerfile.cpu (1)

52-52: Path entry for ppc64le is unconditional

/opt/texlive/2025/bin/powerpc64le-unknown-linux-gnu is prepended even on x86_64 builds where the directory does not exist. While harmless, each command invocation incurs an extra failed stat and slightly slows PATH lookup.

Consider gating the ENV line on architecture:

ARG ARCH=$(uname -m)
RUN if [ "$ARCH" = "ppc64le" ]; then \
      echo 'export PATH="/opt/texlive/2025/bin/powerpc64le-unknown-linux-gnu:$PATH"' >> /etc/profile.d/texlive.sh ; \
    fi
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between aef052c and 7184ab0.

📒 Files selected for processing (2)
  • jupyter/minimal/ubi9-python-3.11/Dockerfile.cpu (2 hunks)
  • jupyter/utils/install_pdf_deps.sh (1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (2)
  • GitHub Check: Generate job matrix
  • GitHub Check: pytest-tests

@jiridanek
Copy link
Member

My preferred solution would be to base the workbench images on red hat enterprise linux, instead of ubi, as to have access to xetex rpms. This would mean rhel for shipping product and centos stream for opendatahub version. That way we'd avoid the lengthy build (I am pretty sure it's gonna be lengthy, completely unsuitable for qemu-user emulation, unless caching is employed, and multistage dockerfile is used to improve caching).

This is something we'd have to agree on, if we want to go that way. In general, I'd love to see xetex installed from some trustworthy binary artifacts. Most conveniently, these should be built by Red Hat, so we can ship them unrestrainedly in the paid product.

@openshift-ci openshift-ci bot added size/l and removed size/m labels Jun 27, 2025
@openshift-ci openshift-ci bot added size/l and removed size/l labels Jun 27, 2025
@puneetsharma21
Copy link
Author

@jiridanek Thanks for the detailed suggestion! You're right — building TeX Live from source is quite heavy and slow, especially under QEMU emulation. However, at this point, sticking with UBI is necessary due to the TeX Live an Pandoc in RHEL is outdated versions lacking features we need.
We're also actively looking into using multi-stage Dockerfiles to better isolate build dependencies and reduce final image size. That should help improve caching and avoid keeping heavy build tools in the final layer

@jiridanek
Copy link
Member

However, at this point, sticking with UBI is necessary due to the TeX Live an Pandoc in RHEL is outdated versions lacking features we need.

This makes no sense, UBI is a subset of RHEL!

@puneetsharma21
Copy link
Author

@jiridanek Actually, while x86-based RHEL/UBI images ship with more up-to-date versions of TeX Live and Pandoc,
the ppc64le (Power) architecture lags behind significantly. On Power, the versions available from official Red Hat or EPEL repositories are quite outdated.

Because of this, we’re currently building TeX Live and Pandoc from source on Power — even though it’s resource-intensive — to ensure compatibility and functionality. We're not sure those older versions should be preferred in the long term, especially for advanced notebook workflows.

@jiridanek
Copy link
Member

jiridanek commented Jun 27, 2025

According to https://access.redhat.com/downloads/content/texlive-xetex/20240311-6.el10/x86_64/fd431d51/package

  • in RHEL10 there is texlive-xetex-20240311-6.el10.s390x.rpm
  • in RHEL9 there is texlive-xetex-20200406-26.el9_2.s390x.rpm

That's the same versions I see available for x86-64 too. Is this too old for you?

Pandoc does not seem to be available in RHEL anymore, it was dropped from distribution in RHEL8.

edit: ppc64le same xetex versions

Screenshot 2025-06-27 at 9 15 10 AM

@puneetsharma21
Copy link
Author

Thanks, @jiridanek — you're right that the versions listed for RHEL are technically the same across architectures. However.,

📌 On x86_64, we use a xetex version from 2025 (installed via upstream binaries or tlmgr), and this is already integrated into our notebook workflows .

📌 On ppc64le, the latest available xetex version in RHEL 9 is still from 2020

@openshift-ci openshift-ci bot added size/l and removed size/l labels Jul 3, 2025
@puneetsharma21 puneetsharma21 marked this pull request as ready for review July 3, 2025 21:34
@openshift-ci openshift-ci bot requested review from andyatmiami and caponetto July 3, 2025 21:34
@openshift-ci openshift-ci bot added size/l and removed size/l labels Jul 3, 2025
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 4

🧹 Nitpick comments (2)
jupyter/utils/install_texlive.sh (2)

27-28: Quote $(nproc) to avoid word-splitting warnings.

-  make -j$(nproc)
+  make -j"$(nproc)"

41-50: Minor robustness & cleanup for the x86_64 branch.

  1. install-tl-unx.tar.gz can be extracted directly: tar xzf … (no need for zcat | tar pipeline).
  2. After installation, remove the installer directory and tarball to keep the layer small.
-  zcat < install-tl-unx.tar.gz | tar xf -
+  tar xzf install-tl-unx.tar.gz+  rm -rf install-tl-unx.tar.gz install-tl-2*
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7184ab0 and 2ca6f7d.

📒 Files selected for processing (3)
  • jupyter/minimal/ubi9-python-3.11/Dockerfile.cpu (3 hunks)
  • jupyter/utils/install_pandoc.sh (1 hunks)
  • jupyter/utils/install_texlive.sh (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • jupyter/minimal/ubi9-python-3.11/Dockerfile.cpu
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation. Issue #1291 was created with comprehensive problem description, multiple solution options, acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/kustomize/base/service.yaml:5-15
Timestamp: 2025-07-02T18:59:15.788Z
Learning: jiridanek creates targeted GitHub issues for specific test quality improvements identified during PR reviews in opendatahub-io/notebooks. Issue #1268 demonstrates this by converting a review comment about insufficient tf2onnx conversion test validation into a comprehensive improvement plan with clear acceptance criteria, code examples, and ROCm-specific context.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/run-code-server.sh:7-10
Timestamp: 2025-07-03T14:01:22.819Z
Learning: jiridanek requested GitHub issue creation for container startup robustness and lifecycle management improvements in codeserver/ubi9-python-3.12/run-code-server.sh during PR #1269 review. A comprehensive issue was created covering race conditions, failure detection, process lifecycle coupling, and signal handling with detailed problem descriptions, multiple solution options, phased acceptance criteria, testing approach, and proper context linking, following the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/run-code-server.sh:7-10
Timestamp: 2025-07-03T14:01:22.819Z
Learning: jiridanek requested GitHub issue creation for container startup robustness and lifecycle management improvements in codeserver/ubi9-python-3.12/run-code-server.sh during PR #1269 review. Issue #1298 was successfully created with comprehensive problem description covering race conditions, failure detection, orphaned processes, and signal handling, along with multiple solution options, phased acceptance criteria, testing approach, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/nginx/api/kernels/access.cgi:6-6
Timestamp: 2025-07-03T16:17:05.475Z
Learning: jiridanek requested GitHub issue creation for CGI script health-check URL configurability and timeout improvement in codeserver/ubi9-python-3.12/nginx/api/kernels/access.cgi during PR #1269 review. The request follows the established pattern of systematic code quality improvements with comprehensive issue creation covering problem description, solution details, acceptance criteria, implementation guidance, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/nginx/api/kernels/access.cgi:8-10
Timestamp: 2025-07-03T14:01:27.789Z
Learning: jiridanek requested GitHub issue creation for JSON parsing robustness improvement in codeserver/ubi9-python-3.12/nginx/api/kernels/access.cgi during PR #1269 review, specifically for replacing fragile grep/awk/date chain with jq-based JSON parsing to improve reliability and maintainability. Issue #1299 was successfully created with comprehensive problem description, solution details, acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/nginx/api/kernels/access.cgi:8-10
Timestamp: 2025-07-03T14:01:27.789Z
Learning: jiridanek requested GitHub issue creation for JSON parsing robustness improvement in codeserver/ubi9-python-3.12/nginx/api/kernels/access.cgi during PR #1269 review, specifically for replacing fragile grep/awk/date chain with jq-based JSON parsing to improve reliability and maintainability. Issue was created with comprehensive problem description, solution details, acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/nginx/root/opt/app-root/etc/generate_container_user:4-9
Timestamp: 2025-07-03T16:05:35.448Z
Learning: jiridanek requested GitHub issue creation for shell script error handling improvements in codeserver/ubi9-python-3.12/nginx/root/opt/app-root/etc/generate_container_user during PR #1269 review. A comprehensive issue was created covering silent failures, unquoted variable expansions, missing template validation, and strict mode implementation with detailed problem descriptions, phased acceptance criteria, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/nginx/api/kernels/access.cgi:6-6
Timestamp: 2025-07-03T16:17:05.475Z
Learning: jiridanek requested GitHub issue creation for CGI script health-check URL configurability and timeout improvement in codeserver/ubi9-python-3.12/nginx/api/kernels/access.cgi during PR #1269 review. Issue #1312 was successfully created with comprehensive problem description covering hard-coded URL limitations, timeout protection, error handling, acceptance criteria, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements.
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#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-03T07:03:45.020Z
Learning: The Python 3.11 infrastructure for ROCm TensorFlow images in opendatahub-io/notebooks is already properly configured in the Makefile with both BASE_DIRS entries for Pipfile lock renewals and all-images targets for CI builds, requiring only commenting out the corresponding Python 3.12 entries when downgrading due to wheel availability issues.
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.
jupyter/utils/install_texlive.sh (2)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation. Issue #1291 was created with comprehensive problem description, multiple solution options, acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation.
jupyter/utils/install_pandoc.sh (3)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-03T14:04:05.280Z
Learning: In opendatahub-io/notebooks, shell scripting robustness and efficiency issues in extension management loops (such as unquoted globs, word-splitting, and unnecessary repeated copies in run-code-server.sh) are systematically tracked and fixed by quoting variables, using `cp -a --`, and toggling `nullglob`, following the established pattern of operational correctness improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation. Issue #1291 was created with comprehensive problem description, multiple solution options, acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation.
🪛 Shellcheck (0.10.0)
jupyter/utils/install_texlive.sh

[warning] 27-27: Quote this to prevent word splitting.

(SC2046)

jupyter/utils/install_pandoc.sh

[warning] 22-22: Quote this to prevent word splitting.

(SC2046)

🔇 Additional comments (1)
jupyter/utils/install_texlive.sh (1)

35-38: export PATH=… is ephemeral in Docker build layers.

The new PATH is lost once the script finishes.
Add the TeX Live bin directory in the Dockerfile (e.g. ENV PATH="/usr/local/texlive/bin/powerpc64le-unknown-linux-gnu:$PATH") or create a profile.d snippet; otherwise downstream layers and runtime shells will not find pdflatex.

Signed-off-by: puneetsharma21 <puneet.sharma21@ibm.com>
@openshift-ci openshift-ci bot added size/l and removed size/l labels Jul 9, 2025
Signed-off-by: puneetsharma21 <puneet.sharma21@ibm.com>
@openshift-ci openshift-ci bot added size/l and removed size/l labels Jul 10, 2025
Signed-off-by: puneetsharma21 <puneet.sharma21@ibm.com>
@openshift-ci openshift-ci bot added size/l and removed size/l labels Jul 11, 2025
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

♻️ Duplicate comments (1)
jupyter/minimal/ubi9-python-3.12/Dockerfile.cpu (1)

4-4: Use of :latest base image already tracked in issue #1242 – no further action here
The repeated discussion about pinning the UBI base image is covered by the standing backlog issue; not blocking this PR.

🧹 Nitpick comments (1)
jupyter/minimal/ubi9-python-3.12/Dockerfile.cpu (1)

11-17: Collapse the three RUN layers and delete helper scripts to shrink the builder image
You can shave ~40 MB and speed up caching:

-RUN chmod +x install_texlive.sh install_pandoc.sh
-
-RUN ./install_texlive.sh
-RUN ./install_pandoc.sh
+RUN chmod +x install_texlive.sh install_pandoc.sh && \
+    ./install_texlive.sh && \
+    ./install_pandoc.sh && \
+    rm -f install_texlive.sh install_pandoc.sh
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b009cdd and f124aa1.

📒 Files selected for processing (1)
  • jupyter/minimal/ubi9-python-3.12/Dockerfile.cpu (2 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue was created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue #1361 was successfully created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation. Issue #1291 was created with comprehensive problem description, multiple solution options, acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.096Z
Learning: jiridanek requested GitHub issue creation for RStudio py311 Tekton push pipelines during PR #1379 review. Issue #1384 was successfully created covering two RStudio variants (CPU and CUDA) found in manifests/base/params-latest.env, with comprehensive problem description, implementation requirements following the same pattern as other workbench pipelines, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.096Z
Learning: jiridanek requested GitHub issue creation for adding RStudio py311 Tekton push pipelines during PR #1379 review, referencing existing registry entries in manifests/base/params-latest.env but missing corresponding .tekton pipeline files. A comprehensive issue was created with detailed problem description, implementation requirements following the same pattern as other workbench pipelines, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm:50-50
Timestamp: 2025-07-08T19:30:01.738Z
Learning: jiridanek requested GitHub issue creation for multi-architecture support in ROCm TensorFlow image during PR #1333 review. Issue #1346 was created with comprehensive problem description covering hardcoded x86_64 architecture breaking multi-arch support, detailed impact analysis, three solution options (runtime detection, BuildKit TARGETARCH integration, hybrid approach) with pros/cons analysis, comprehensive acceptance criteria covering core requirements and testing, phased implementation guidance, related files identification, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:65-66
Timestamp: 2025-07-09T12:31:02.033Z
Learning: jiridanek requested GitHub issue creation for MSSQL repo file hardcoding problem during PR #1320 review. Issue #1363 was created and updated with comprehensive problem description covering hardcoded x86_64 MSSQL repo files breaking multi-architecture builds across 10 affected Dockerfiles (including datascience, CUDA, ROCm, and TrustyAI variants), detailed root cause analysis, three solution options with code examples, clear acceptance criteria for all image types, implementation guidance following established multi-architecture patterns, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:42-52
Timestamp: 2025-07-09T12:29:56.162Z
Learning: jiridanek requested GitHub issue creation for OpenShift client architecture mapping problem affecting 29 Dockerfiles during PR #1320 review. Issue was created with comprehensive analysis covering all affected files using $(uname -m) returning 'aarch64' but OpenShift mirror expecting 'arm64', systematic solution using BuildKit TARGETARCH mapping with proper amd64→x86_64 and arm64→arm64 conversion, detailed acceptance criteria, and implementation guidance, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/tensorflow/ubi9-python-3.12/Dockerfile.cuda:38-38
Timestamp: 2025-07-08T19:30:20.513Z
Learning: jiridanek requested GitHub issue creation for multi-architecture support in TensorFlow CUDA runtime image during PR #1333 review. Issue was created with comprehensive problem description covering hardcoded NVARCH limitation, multiple solution options using TARGETARCH build argument with architecture mapping, acceptance criteria for multi-architecture builds, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: jupyter/minimal/ubi9-python-3.11/Dockerfile.cuda:29-38
Timestamp: 2025-07-04T17:07:52.656Z
Learning: In the opendatahub-io/notebooks repository, modern Docker with BuildKit automatically provides build arguments like TARGETARCH in the global scope for FROM instructions, but these arguments must be explicitly declared with ARG statements inside build stages where they will be used. The ARG declaration should be placed within the stage that uses it, not moved to the global scope, as this is the correct pattern for modern Docker/Podman/Buildah environments.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:40-42
Timestamp: 2025-07-04T17:08:02.399Z
Learning: In the opendatahub-io/notebooks repository, when using multi-architecture Dockerfiles with BuildKit, the implicit build argument TARGETARCH is automatically available in the global scope for FROM instructions without explicit declaration. However, if TARGETARCH is used within a build stage, it must be declared explicitly within that stage. The current placement pattern (declaring ARG TARGETARCH after FROM instructions that use it) is correct for modern Docker/Podman/Buildah environments and does not require compatibility with older Docker versions.
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#1306
File: jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu:4-4
Timestamp: 2025-07-04T05:49:10.314Z
Learning: jiridanek directs base image pinning security concerns to existing comprehensive issue #1242 "Improve Docker FROM image versioning by avoiding :latest tags" rather than addressing them in individual PRs, continuing the established pattern of systematic security and quality tracking in opendatahub-io/notebooks.
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: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:34-35
Timestamp: 2025-07-04T10:41:13.061Z
Learning: In the opendatahub-io/notebooks repository, when adapting NVIDIA CUDA Dockerfiles, the project intentionally maintains consistency with upstream NVIDIA patterns even when it might involve potential risks like empty variable expansions in package installation commands. This is considered acceptable because the containers only run on RHEL 9 with known yum/dnf behavior, and upstream consistency is prioritized over defensive coding practices.
jupyter/minimal/ubi9-python-3.12/Dockerfile.cpu (12)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu:135-136
Timestamp: 2025-07-04T05:52:49.464Z
Learning: jiridanek requested GitHub issue creation for improving fragile sed-based Jupyter kernel display_name modification in jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu during PR #1306 review. Issue #1321 was created with comprehensive problem description covering JSON corruption risks, greedy regex patterns, maintenance burden, and proposed Python-based JSON parsing solution with detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: atheo89
PR: opendatahub-io/notebooks#1258
File: codeserver/ubi9-python-3.11/Dockerfile.cpu:32-32
Timestamp: 2025-07-07T11:08:48.524Z
Learning: atheo89 requested GitHub issue creation for multi-architecture Dockerfile improvements during PR #1258 review, specifically for enhancing structural consistency across Docker stages, replacing $(uname -m) with ${TARGETARCH} for cross-architecture builds, and adding OCI-compliant metadata labels. Issue #1332 was created with comprehensive problem description, phased implementation approach, detailed acceptance criteria, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:34-35
Timestamp: 2025-07-04T10:41:13.061Z
Learning: In the opendatahub-io/notebooks repository, when adapting NVIDIA CUDA Dockerfiles, the project intentionally maintains consistency with upstream NVIDIA patterns even when it might involve potential risks like empty variable expansions in package installation commands. This is considered acceptable because the containers only run on RHEL 9 with known yum/dnf behavior, and upstream consistency is prioritized over defensive coding practices.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue was created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation. Issue #1291 was created with comprehensive problem description, multiple solution options, acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue #1361 was successfully created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/kustomize/base/kustomization.yaml:8-12
Timestamp: 2025-07-08T19:09:48.746Z
Learning: jiridanek requested GitHub issue creation for misleading CUDA prefix in TrustyAI image tags during PR #1306 review, affecting both Python 3.11 and 3.12 versions. Issue #1338 was created with comprehensive problem description covering both affected images, repository pattern analysis comparing correct vs incorrect naming conventions, clear solution with code examples, detailed acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:40-42
Timestamp: 2025-07-04T17:08:02.399Z
Learning: In the opendatahub-io/notebooks repository, when using multi-architecture Dockerfiles with BuildKit, the implicit build argument TARGETARCH is automatically available in the global scope for FROM instructions without explicit declaration. However, if TARGETARCH is used within a build stage, it must be declared explicitly within that stage. The current placement pattern (declaring ARG TARGETARCH after FROM instructions that use it) is correct for modern Docker/Podman/Buildah environments and does not require compatibility with older Docker versions.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-pytorch/ubi9-python-3.12/de-vendor-torch.sh:9-12
Timestamp: 2025-07-08T19:28:15.791Z
Learning: jiridanek requested GitHub issue creation for runtime detection improvement of Python site-packages paths during PR #1333 review. Issue #1344 was created with comprehensive problem description covering hard-coded path fragility across UBI9 distributions, extensive affected files analysis including 4 de-vendor scripts, 30+ Dockerfiles with chmod operations, and 12+ pip.conf configurations, runtime detection solution using sysconfig module, implementation areas breakdown, benefits analysis, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: jupyter/minimal/ubi9-python-3.11/Dockerfile.cuda:29-38
Timestamp: 2025-07-04T17:07:52.656Z
Learning: In the opendatahub-io/notebooks repository, modern Docker with BuildKit automatically provides build arguments like TARGETARCH in the global scope for FROM instructions, but these arguments must be explicitly declared with ARG statements inside build stages where they will be used. The ARG declaration should be placed within the stage that uses it, not moved to the global scope, as this is the correct pattern for modern Docker/Podman/Buildah environments.
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.

Signed-off-by: puneetsharma21 <puneet.sharma21@ibm.com>
Copy link
Contributor

openshift-ci bot commented Jul 14, 2025

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign paulovmr for approval. For more information see the Code Review Process.

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added size/l and removed size/l labels Jul 14, 2025
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 3

♻️ Duplicate comments (1)
jupyter/utils/install_pandoc.sh (1)

43-49: Add version check and expose pandoc on PATH for amd64 installation
The amd64 branch unpacks Pandoc but never verifies the binary or makes it accessible via the default $PATH, unlike the ppc64le block. Let’s mirror the sanity check and expose step to catch extraction errors early and ensure pandoc is on the path.

• File: jupyter/utils/install_pandoc.sh
• Location: under the elif [[ "$ARCH" == "amd64" ]]; then block (around lines 43–49)

   tar xvzf /tmp/pandoc.tar.gz --strip-components 1 -C /usr/local/pandoc/
   rm -f /tmp/pandoc.tar.gz
+
+  # Expose pandoc on PATH and verify installation
+  ln -sf /usr/local/pandoc/bin/pandoc /usr/local/bin/pandoc
+  /usr/local/pandoc/bin/pandoc --version
🧹 Nitpick comments (4)
jupyter/utils/install_texlive.sh (2)

16-20: Trim image size & network traffic by cleaning package cache and removing artefacts

dnf install -y … leaves the /var/cache/dnf layer (~150 MB) and the two
tarballs behind. Add explicit cleanup to keep the final image lean:

 dnf install -y gcc-toolset-13 perl make libX11-devel libXt-devel \
   zlib-devel freetype-devel libpng-devel ncurses-devel \
   gd-devel libtool wget tar xz bison flex libXaw-devel
+dnf clean all && rm -rf /var/cache/dnf-rm -rf /texlive-20250308-source /texlive-build
+rm -rf /texlive-20250308-source /texlive-build \
+       texlive-20250308-source.tar.xz install-tl-unx.tar.gz

Also applies to: 40-41


78-79: Minor style nit – use tar -xzf directly

Using zcat | tar xf - is functionally fine but slower and less readable. A
single tar -xzf install-tl-unx.tar.gz suffices.

jupyter/utils/install_pandoc.sh (2)

4-12: Mapping defines arm64 & s390x but immediately rejects them
UNAME_TO_GOARCH advertises support for aarch64arm64 and s390x, yet the case-statement only handles ppc64le and amd64, so those two archs fall through to “unsupported”. Either:

  1. drop them from the map, or
  2. add proper branches (even a TODO stub) so the intent is explicit.

Leaving dead code confuses readers and automation alike.

Also applies to: 50-52


37-38: rm -rf ~/.cabal ~/.ghc may wipe host-mounted caches
If the script ever runs in a container with a volume-mounted home (CI cache), this line deletes the cache instead of leveraging it. Consider restricting the cleanup to the build container layer (/root/.cabal & /root/.ghc) or providing a knob to skip it.

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f124aa1 and 510e5a0.

📒 Files selected for processing (4)
  • jupyter/minimal/ubi9-python-3.11/Dockerfile.cpu (3 hunks)
  • jupyter/minimal/ubi9-python-3.12/Dockerfile.cpu (2 hunks)
  • jupyter/utils/install_pandoc.sh (1 hunks)
  • jupyter/utils/install_texlive.sh (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • jupyter/minimal/ubi9-python-3.11/Dockerfile.cpu
  • jupyter/minimal/ubi9-python-3.12/Dockerfile.cpu
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue was created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue #1361 was successfully created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation. Issue #1291 was created with comprehensive problem description, multiple solution options, acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.131Z
Learning: jiridanek requested GitHub issue creation for RStudio py311 Tekton push pipelines during PR #1379 review. Issue #1384 was successfully created covering two RStudio variants (CPU and CUDA) found in manifests/base/params-latest.env, with comprehensive problem description, implementation requirements following the same pattern as other workbench pipelines, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.131Z
Learning: jiridanek requested GitHub issue creation for adding RStudio py311 Tekton push pipelines during PR #1379 review, referencing existing registry entries in manifests/base/params-latest.env but missing corresponding .tekton pipeline files. A comprehensive issue was created with detailed problem description, implementation requirements following the same pattern as other workbench pipelines, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm:50-50
Timestamp: 2025-07-08T19:30:01.738Z
Learning: jiridanek requested GitHub issue creation for multi-architecture support in ROCm TensorFlow image during PR #1333 review. Issue #1346 was created with comprehensive problem description covering hardcoded x86_64 architecture breaking multi-arch support, detailed impact analysis, three solution options (runtime detection, BuildKit TARGETARCH integration, hybrid approach) with pros/cons analysis, comprehensive acceptance criteria covering core requirements and testing, phased implementation guidance, related files identification, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:65-66
Timestamp: 2025-07-09T12:31:02.033Z
Learning: jiridanek requested GitHub issue creation for MSSQL repo file hardcoding problem during PR #1320 review. Issue #1363 was created and updated with comprehensive problem description covering hardcoded x86_64 MSSQL repo files breaking multi-architecture builds across 10 affected Dockerfiles (including datascience, CUDA, ROCm, and TrustyAI variants), detailed root cause analysis, three solution options with code examples, clear acceptance criteria for all image types, implementation guidance following established multi-architecture patterns, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:42-52
Timestamp: 2025-07-09T12:29:56.162Z
Learning: jiridanek requested GitHub issue creation for OpenShift client architecture mapping problem affecting 29 Dockerfiles during PR #1320 review. Issue was created with comprehensive analysis covering all affected files using $(uname -m) returning 'aarch64' but OpenShift mirror expecting 'arm64', systematic solution using BuildKit TARGETARCH mapping with proper amd64→x86_64 and arm64→arm64 conversion, detailed acceptance criteria, and implementation guidance, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. The automated issue creation failed despite appearing successful, so comprehensive issue content was provided for manual creation covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: jupyter/minimal/ubi9-python-3.11/Dockerfile.cuda:29-38
Timestamp: 2025-07-04T17:07:52.656Z
Learning: In the opendatahub-io/notebooks repository, modern Docker with BuildKit automatically provides build arguments like TARGETARCH in the global scope for FROM instructions, but these arguments must be explicitly declared with ARG statements inside build stages where they will be used. The ARG declaration should be placed within the stage that uses it, not moved to the global scope, as this is the correct pattern for modern Docker/Podman/Buildah environments.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:40-42
Timestamp: 2025-07-04T17:08:02.399Z
Learning: In the opendatahub-io/notebooks repository, when using multi-architecture Dockerfiles with BuildKit, the implicit build argument TARGETARCH is automatically available in the global scope for FROM instructions without explicit declaration. However, if TARGETARCH is used within a build stage, it must be declared explicitly within that stage. The current placement pattern (declaring ARG TARGETARCH after FROM instructions that use it) is correct for modern Docker/Podman/Buildah environments and does not require compatibility with older Docker versions.
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#1306
File: jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu:4-4
Timestamp: 2025-07-04T05:49:10.314Z
Learning: jiridanek directs base image pinning security concerns to existing comprehensive issue #1242 "Improve Docker FROM image versioning by avoiding :latest tags" rather than addressing them in individual PRs, continuing the established pattern of systematic security and quality tracking in opendatahub-io/notebooks.
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: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:34-35
Timestamp: 2025-07-04T10:41:13.061Z
Learning: In the opendatahub-io/notebooks repository, when adapting NVIDIA CUDA Dockerfiles, the project intentionally maintains consistency with upstream NVIDIA patterns even when it might involve potential risks like empty variable expansions in package installation commands. This is considered acceptable because the containers only run on RHEL 9 with known yum/dnf behavior, and upstream consistency is prioritized over defensive coding practices.
jupyter/utils/install_pandoc.sh (24)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. The automated issue creation failed despite appearing successful, so comprehensive issue content was provided for manual creation covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue was created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue #1361 was successfully created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-03T14:04:05.280Z
Learning: In opendatahub-io/notebooks, shell scripting robustness and efficiency issues in extension management loops (such as unquoted globs, word-splitting, and unnecessary repeated copies in run-code-server.sh) are systematically tracked and fixed by quoting variables, using `cp -a --`, and toggling `nullglob`, following the established pattern of operational correctness improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue #1364 was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation. Issue #1291 was created with comprehensive problem description, multiple solution options, acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:39:23.433Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue #1373 was successfully created on the second attempt with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: atheo89
PR: opendatahub-io/notebooks#1258
File: codeserver/ubi9-python-3.11/Dockerfile.cpu:32-32
Timestamp: 2025-07-07T11:08:48.524Z
Learning: atheo89 requested GitHub issue creation for multi-architecture Dockerfile improvements during PR #1258 review, specifically for enhancing structural consistency across Docker stages, replacing $(uname -m) with ${TARGETARCH} for cross-architecture builds, and adding OCI-compliant metadata labels. Issue #1332 was created with comprehensive problem description, phased implementation approach, detailed acceptance criteria, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm:50-50
Timestamp: 2025-07-08T19:30:01.738Z
Learning: jiridanek requested GitHub issue creation for multi-architecture support in ROCm TensorFlow image during PR #1333 review. Issue #1346 was created with comprehensive problem description covering hardcoded x86_64 architecture breaking multi-arch support, detailed impact analysis, three solution options (runtime detection, BuildKit TARGETARCH integration, hybrid approach) with pros/cons analysis, comprehensive acceptance criteria covering core requirements and testing, phased implementation guidance, related files identification, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:42-52
Timestamp: 2025-07-09T12:29:56.162Z
Learning: jiridanek requested GitHub issue creation for OpenShift client architecture mapping problem affecting 29 Dockerfiles during PR #1320 review. Issue was created with comprehensive analysis covering all affected files using $(uname -m) returning 'aarch64' but OpenShift mirror expecting 'arm64', systematic solution using BuildKit TARGETARCH mapping with proper amd64→x86_64 and arm64→arm64 conversion, detailed acceptance criteria, and implementation guidance, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/run-code-server.sh:17-17
Timestamp: 2025-07-03T12:26:24.084Z
Learning: jiridanek requests GitHub issue creation for shell script quality improvements identified during PR #1269 review, specifically for unquoted command substitution in codeserver/ubi9-python-3.12/run-code-server.sh. Issue #1283 was created with comprehensive problem descriptions, acceptance criteria, implementation guidance, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/run-nginx.sh:18-23
Timestamp: 2025-07-03T16:17:23.065Z
Learning: jiridanek requested GitHub issue creation for shell script variable quoting security concern in codeserver/ubi9-python-3.12/run-nginx.sh during PR #1269 review. The issue covers unquoted variables NB_PREFIX, NOTEBOOK_ARGS, and BASE_URL that pose security risks including command injection, word-splitting vulnerabilities, and globbing issues. A comprehensive issue was created with detailed problem description, security concerns, solution with code examples, acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/run-nginx.sh:23-23
Timestamp: 2025-07-03T12:29:24.067Z
Learning: jiridanek requested GitHub issue creation for shell script safety improvement in codeserver/ubi9-python-3.12/run-nginx.sh during PR #1269 review, specifically for replacing unsafe in-place file modification with tee. Issue #1285 was created with comprehensive problem descriptions, risk assessment, recommended atomic file operations solution, acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/nginx/root/usr/share/container-scripts/nginx/common.sh:4-11
Timestamp: 2025-07-03T12:08:47.691Z
Learning: jiridanek requests GitHub issue creation for shell script quality improvements identified during PR #1269 review, specifically for POSIX compliance and security issues in codeserver/ubi9-python-3.12/nginx/root/usr/share/container-scripts/nginx/common.sh. Issue #1275 was created with comprehensive problem descriptions, acceptance criteria, implementation guidance, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/nginx/root/opt/app-root/etc/generate_container_user:4-9
Timestamp: 2025-07-03T16:05:35.448Z
Learning: jiridanek requested GitHub issue creation for shell script error handling improvements in codeserver/ubi9-python-3.12/nginx/root/opt/app-root/etc/generate_container_user during PR #1269 review. A comprehensive issue was created covering silent failures, unquoted variable expansions, missing template validation, and strict mode implementation with detailed problem descriptions, phased acceptance criteria, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-pytorch/ubi9-python-3.12/de-vendor-torch.sh:9-12
Timestamp: 2025-07-08T19:28:15.791Z
Learning: jiridanek requested GitHub issue creation for runtime detection improvement of Python site-packages paths during PR #1333 review. Issue #1344 was created with comprehensive problem description covering hard-coded path fragility across UBI9 distributions, extensive affected files analysis including 4 de-vendor scripts, 30+ Dockerfiles with chmod operations, and 12+ pip.conf configurations, runtime detection solution using sysconfig module, implementation areas breakdown, benefits analysis, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/run-code-server.sh:5-5
Timestamp: 2025-07-03T12:25:26.453Z
Learning: jiridanek requested GitHub issue creation for shell script safety improvements identified during PR #1269 review, specifically for unsafe globbing patterns in codeserver/ubi9-python-3.12/run-code-server.sh. Issue #1281 was created with comprehensive problem descriptions, solution options, acceptance criteria, and proper context linking, following the established pattern for systematic tracking of technical improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/run-code-server.sh:20-40
Timestamp: 2025-07-03T12:27:09.739Z
Learning: jiridanek requested GitHub issue creation for shell script error handling improvements in codeserver/ubi9-python-3.12/run-code-server.sh create_dir_and_file function during PR #1269 review. Issue #1284 was created with comprehensive problem description, acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/utils/process.sh:1-2
Timestamp: 2025-07-03T16:00:46.191Z
Learning: jiridanek requested GitHub issue creation for shell script strict-mode improvement in codeserver/ubi9-python-3.12/utils/process.sh during PR #1269 review. Issue #1303 was created with comprehensive problem description covering silent failures and production risks, phased acceptance criteria for basic strict-mode implementation and enhanced error handling, implementation guidance with code examples and flag explanations, benefits section, and proper context linking, continuing the established pattern of systematic code quality improvements.
jupyter/utils/install_texlive.sh (18)
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue was created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation. Issue #1291 was created with comprehensive problem description, multiple solution options, acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1260
File: jupyter/utils/install_pdf_deps.sh:13-27
Timestamp: 2025-07-03T13:04:11.835Z
Learning: jiridanek requested GitHub issue creation for investigating alternatives to directory move operation in install_pdf_deps.sh during PR #1260 review, specifically to explore cleaner architectural approaches like installing TeX Live directly to /usr/local/texlive/bin instead of using filesystem manipulation post-installation.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-09T10:24:37.290Z
Learning: jiridanek requested GitHub issue creation for TeX Live installation robustness improvements in jupyter/utils/install_pdf_deps.sh during PR #1357 review, specifically for network resilience and error handling improvements to address flaky CI failures. Issue #1361 was successfully created with comprehensive problem description covering network download failures, mirror fallback mechanisms, retry logic, caching strategies, multiple solution options with code examples, detailed acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-03T14:04:05.280Z
Learning: In opendatahub-io/notebooks, shell scripting robustness and efficiency issues in extension management loops (such as unquoted globs, word-splitting, and unnecessary repeated copies in run-code-server.sh) are systematically tracked and fixed by quoting variables, using `cp -a --`, and toggling `nullglob`, following the established pattern of operational correctness improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/utils/process.sh:1-2
Timestamp: 2025-07-03T16:00:46.191Z
Learning: jiridanek requested GitHub issue creation for shell script strict-mode improvement in codeserver/ubi9-python-3.12/utils/process.sh during PR #1269 review. Issue #1303 was created with comprehensive problem description covering silent failures and production risks, phased acceptance criteria for basic strict-mode implementation and enhanced error handling, implementation guidance with code examples and flag explanations, benefits section, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/run-code-server.sh:17-17
Timestamp: 2025-07-03T12:26:24.084Z
Learning: jiridanek requests GitHub issue creation for shell script quality improvements identified during PR #1269 review, specifically for unquoted command substitution in codeserver/ubi9-python-3.12/run-code-server.sh. Issue #1283 was created with comprehensive problem descriptions, acceptance criteria, implementation guidance, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/run-code-server.sh:20-40
Timestamp: 2025-07-03T12:27:09.739Z
Learning: jiridanek requested GitHub issue creation for shell script error handling improvements in codeserver/ubi9-python-3.12/run-code-server.sh create_dir_and_file function during PR #1269 review. Issue #1284 was created with comprehensive problem description, acceptance criteria, implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. The automated issue creation failed despite appearing successful, so comprehensive issue content was provided for manual creation covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue #1364 was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:02:13.228Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue was created with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: scripts/buildinputs/dockerfile.go:35-35
Timestamp: 2025-07-10T15:39:23.433Z
Learning: jiridanek requested GitHub issue creation for improving architecture detection in buildinputs tool during PR #1320 review. Issue #1373 was successfully created on the second attempt with comprehensive problem description covering qemu-user s390x build failures where runtime.GOARCH returns host architecture instead of target architecture, detailed impact analysis, four solution options (environment variable detection, configuration parameter, platform detection logic, hybrid approach), clear acceptance criteria for multi-architecture support, phased implementation guidance, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: atheo89
PR: opendatahub-io/notebooks#1258
File: codeserver/ubi9-python-3.11/Dockerfile.cpu:32-32
Timestamp: 2025-07-07T11:08:48.524Z
Learning: atheo89 requested GitHub issue creation for multi-architecture Dockerfile improvements during PR #1258 review, specifically for enhancing structural consistency across Docker stages, replacing $(uname -m) with ${TARGETARCH} for cross-architecture builds, and adding OCI-compliant metadata labels. Issue #1332 was created with comprehensive problem description, phased implementation approach, detailed acceptance criteria, implementation guidance with code examples, and proper context linking, continuing the established pattern of systematic code quality improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm:50-50
Timestamp: 2025-07-08T19:30:01.738Z
Learning: jiridanek requested GitHub issue creation for multi-architecture support in ROCm TensorFlow image during PR #1333 review. Issue #1346 was created with comprehensive problem description covering hardcoded x86_64 architecture breaking multi-arch support, detailed impact analysis, three solution options (runtime detection, BuildKit TARGETARCH integration, hybrid approach) with pros/cons analysis, comprehensive acceptance criteria covering core requirements and testing, phased implementation guidance, related files identification, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:40-42
Timestamp: 2025-07-04T17:08:02.399Z
Learning: In the opendatahub-io/notebooks repository, when using multi-architecture Dockerfiles with BuildKit, the implicit build argument TARGETARCH is automatically available in the global scope for FROM instructions without explicit declaration. However, if TARGETARCH is used within a build stage, it must be declared explicitly within that stage. The current placement pattern (declaring ARG TARGETARCH after FROM instructions that use it) is correct for modern Docker/Podman/Buildah environments and does not require compatibility with older Docker versions.
🔇 Additional comments (1)
jupyter/utils/install_texlive.sh (1)

28-28: Ensure gcc-toolset-13 activation does not silently fail

source /opt/rh/gcc-toolset-13/enable will exit the script if the file is
missing (because of set -e). On UBI9 images the path is available only after
dnf install gcc-toolset-13, but in minimal images the SCL infrastructure may
be absent.

Consider:

if [[ -f /opt/rh/gcc-toolset-13/enable ]]; then
  source /opt/rh/gcc-toolset-13/enable
else
  echo "gcc-toolset-13 not found" >&2; exit 1
fi

Comment on lines +81 to +82
mv /usr/local/texlive/bin/"$(uname -m)-linux" /usr/local/texlive/bin/linux
cd /usr/local/texlive/bin/linux
Copy link
Contributor

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Derive TeX Live binary dir dynamically instead of assuming $(uname -m)-linux

The installer names the bin dir <arch>-linux, but on future releases or
cross-builds that may differ. Fail-proof alternative:

-mv /usr/local/texlive/bin/"$(uname -m)-linux" /usr/local/texlive/bin/linux
+BIN_DIR=$(find /usr/local/texlive/bin -maxdepth 1 -type d -name '*-linux' | head -n1)
+mv "$BIN_DIR" /usr/local/texlive/bin/linux
📝 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.

Suggested change
mv /usr/local/texlive/bin/"$(uname -m)-linux" /usr/local/texlive/bin/linux
cd /usr/local/texlive/bin/linux
BIN_DIR=$(find /usr/local/texlive/bin -maxdepth 1 -type d -name '*-linux' | head -n1)
mv "$BIN_DIR" /usr/local/texlive/bin/linux
cd /usr/local/texlive/bin/linux
🤖 Prompt for AI Agents
In jupyter/utils/install_texlive.sh around lines 81 to 82, the script assumes
the TeX Live binary directory is named using the pattern "$(uname -m)-linux",
which may not hold true for future releases or cross-builds. Modify the script
to dynamically determine the actual TeX Live binary directory name instead of
hardcoding it. This can be done by listing the directories under
/usr/local/texlive/bin and selecting the appropriate one programmatically before
moving and changing into it.

Comment on lines +15 to +17
dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
dnf install -y cabal-install ghc gmp-devel

Copy link
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue

git missing – build will exit on first git clone
git is not part of the UBI9 minimal image and is not added to the build-deps list, so the very next command (git clone) fails on ppc64le.

-  dnf install -y cabal-install ghc gmp-devel
+  dnf install -y git cabal-install ghc gmp-devel-  dnf remove -y cabal-install ghc gmp-devel
+  dnf remove -y git cabal-install ghc gmp-devel
🤖 Prompt for AI Agents
In jupyter/utils/install_pandoc.sh around lines 15 to 17, the script installs
dependencies but misses installing git, which causes the subsequent git clone
command to fail on ppc64le. Add git to the list of packages installed by dnf to
ensure the git clone command succeeds during the build.

Signed-off-by: puneetsharma21 <puneet.sharma21@ibm.com>
@openshift-ci openshift-ci bot added size/l and removed size/l labels Jul 14, 2025
Copy link
Contributor

openshift-ci bot commented Jul 14, 2025

@puneetsharma21: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/notebook-jupyter-ubi9-python-3-11-pr-image-mirror 6673212 link true /test notebook-jupyter-ubi9-python-3-11-pr-image-mirror
ci/prow/images 6673212 link true /test images
ci/prow/notebooks-ubi9-e2e-tests 6673212 link true /test notebooks-ubi9-e2e-tests

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants