respect the image tag length limit in gha

[jiridanek]

Error: tag ghcr.io/jiridanek/notebooks/workbench-images:runtime-minimal-ubi9-python-3.11-jd_reduce_need_for_TESTCONTAINERS_DOCKER_SOCKET_OVERRIDE_e87244e39784068b4a429e00eca44b1c94253a28: invalid reference format

https://github.com/jiridanek/notebooks/actions/runs/12938132231/job/36087687905#step:17:49

[jiridanek]

@coderabbitai has this been implemented? is it implemented correctly? see also #631 and the linked prs for associated work

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# First, let's get details about the current issue #862
gh issue view 862 --repo opendatahub-io/notebooks --json title,body,state,labels,assignees,comments

# Then get details about the referenced issue #631
gh issue view 631 --repo opendatahub-io/notebooks --json title,body,state,labels,assignees,comments

# Get the linked PRs from issue #631
gh issue view 631 --repo opendatahub-io/notebooks --json title,body | jq -r '.body' | grep -E '#[0-9]+|PR|pull request' || echo "No clear PR references found in body"

Length of output: 3871

---

🏁 Script executed:

#!/bin/bash
# Let's also search for any mentions of these issues in the codebase
rg "#862|#631" --type md -A 3 -B 3

# Search for any related PRs or commits that might reference these issues
git log --oneline --grep="#862" --grep="#631" --grep="862" --grep="631" | head -10

Length of output: 36

---

🏁 Script executed:

#!/bin/bash
# Let's search for any PRs that might be linked to issue #631
gh pr list --repo opendatahub-io/notebooks --search "631 in:title,body" --state all --json number,title,state,url

# Also search for PRs that might reference issue #862
gh pr list --repo opendatahub-io/notebooks --search "862 in:title,body" --state all --json number,title,state,url

Length of output: 624

---

🏁 Script executed:

#!/bin/bash
# Let's examine the specific PRs that were merged to address issue #631
gh pr view 1027 --repo opendatahub-io/notebooks --json title,body,state,mergedAt,files

gh pr view 919 --repo opendatahub-io/notebooks --json title,body,state,mergedAt,files

Length of output: 2593

---

🏁 Script executed:

#!/bin/bash
# Let's look at the GitHub Actions workflow files to see if the fixes are implemented
fd -e yml -e yaml . .github/workflows/ | head -5

# Check for any downcase operations in the workflow files
rg -A 3 -B 3 "downcase|,,}" .github/workflows/ || echo "No downcase operations found"

# Look for any length limiting logic in workflows
rg -A 3 -B 3 "128|cut.*ref|substring" .github/workflows/ || echo "No length limiting found"

Length of output: 2156

---

🏁 Script executed:

#!/bin/bash
# Let's examine the main workflow file that likely handles image building
cat .github/workflows/build-and-push-image.yaml | head -50

# Look for environment variable handling related to REPO, IMAGE_REGISTRY, CACHE
rg -A 5 -B 5 "REPO|IMAGE_REGISTRY|CACHE" .github/workflows/build-and-push-image.yaml

Length of output: 307

---

🏁 Script executed:

#!/bin/bash
# Let's check if there are any current issues with tag length in the workflow
rg "tag.*length|128.*char|invalid.*reference" .github/workflows/ -A 2 -B 2

# Check the actual tag creation logic
rg -A 10 -B 5 "tag.*=" .github/workflows/build-and-push-image.yaml

Length of output: 928

---

🏁 Script executed:

#!/bin/bash
# Let's examine the TEMPLATE workflow that contains the fixes and see how it's being used
cat .github/workflows/build-notebooks-TEMPLATE.yaml | grep -A 15 -B 5 "SANITIZED_REF_NAME"

# Also check if this template is properly used in other workflows
rg "build-notebooks-TEMPLATE" .github/workflows/ -A 2 -B 2

Length of output: 2444

---

🏁 Script executed:

#!/bin/bash
# Let's examine the error from issue #862 more closely and check if it's related to the same workflow
echo "Issue #862 error tag:"
echo "ghcr.io/jiridanek/notebooks/workbench-images:runtime-minimal-ubi9-python-3.11-jd_reduce_need_for_TESTCONTAINERS_DOCKER_SOCKET_OVERRIDE_e87244e39784068b4a429e00eca44b1c94253a28"

# Count the length of this tag
echo "Tag length:"
echo "ghcr.io/jiridanek/notebooks/workbench-images:runtime-minimal-ubi9-python-3.11-jd_reduce_need_for_TESTCONTAINERS_DOCKER_SOCKET_OVERRIDE_e87244e39784068b4a429e00eca44b1c94253a28" | wc -c

# Check what the branch name would be
echo "Branch name portion:"
echo "jd_reduce_need_for_TESTCONTAINERS_DOCKER_SOCKET_OVERRIDE" | wc -c

Length of output: 765

---

🏁 Script executed:

#!/bin/bash
# Let's check if the issue is that the fix is only in the TEMPLATE but not applied to all workflows
ls -la .github/workflows/build-notebooks-*.yaml

# Check if other build workflows use the template or have their own logic
for file in .github/workflows/build-notebooks-*.yaml; do
  echo "=== Checking $file ==="
  if grep -q "SANITIZED_REF_NAME\|cut -c 1-40" "$file"; then
    echo "✅ Has length limiting logic"
  else
    echo "❌ Missing length limiting logic"
  fi
  
  if grep -q "IMAGE_REGISTRY.*,,\|CACHE.*,," "$file"; then
    echo "✅ Has downcase logic"
  else
    echo "❌ Missing downcase logic"
  fi
  echo ""
done

Length of output: 2586

---

🏁 Script executed:

#!/bin/bash
# Let's see the structure of the workflows to understand the relationship
echo "=== TEMPLATE workflow structure ==="
grep -E "^[[:space:]]*name:|^[[:space:]]*uses:|^[[:space:]]*with:" .github/workflows/build-notebooks-TEMPLATE.yaml | head -10

echo "=== Other workflow structures ==="
for file in .github/workflows/build-notebooks-pr*.yaml .github/workflows/build-notebooks-push.yaml; do
  echo "--- $file ---"
  grep -E "^[[:space:]]*name:|^[[:space:]]*uses:|^[[:space:]]*with:" "$file" | head -5
done

Length of output: 1876

---

@jiridanek Yes, the implementation for issue #631 has been completed and is correctly implemented, but issue #862 indicates there's still a problem that needs to be addressed.

Implementation Status Summary:

✅ Issue #631 - Implemented and Working:

• PR ISSUE #631: lowercase the image repository name in github actions #919 (merged Feb 24, 2025): Added lowercase conversion for IMAGE_REGISTRY and CACHE variables
• PR Issue opendatahub-io/notebooks#631: cut the ref name to avoid going over 128 character limit for Docker image tag #1027 (merged Apr 24, 2025): Added branch name limiting to 40 characters to respect Docker's 128-character tag limit

The fixes are properly implemented in .github/workflows/build-notebooks-TEMPLATE.yaml:

# Downcase logic (from PR #919)
- name: downcase IMAGE_REGISTRY and CACHE
  run: |
    echo "IMAGE_REGISTRY=${IMAGE_REGISTRY,,}" >>${GITHUB_ENV}
    echo "CACHE=${CACHE,,}" >>${GITHUB_ENV}

# Length limiting logic (from PR #1027)  
SANITIZED_REF_NAME=$(echo "${{ github.ref_name }}" | sed 's/[^a-zA-Z0-9._-]/_/g') | cut -c 1-40

All other workflows (build-notebooks-pr.yaml, build-notebooks-pr-rhel.yaml, build-notebooks-push.yaml) correctly use this template via the uses: directive.

❌ Issue #862 - Still Occurring:
However, issue #862 shows the same problem is still happening. The error tag is 176 characters:

ghcr.io/jiridanek/notebooks/workbench-images:runtime-minimal-ubi9-python-3.11-jd_reduce_need_for_TESTCONTAINERS_DOCKER_SOCKET_OVERRIDE_e87244e39784068b4a429e00eca44b1c94253a28

With the current fix applied, this should become ~148 characters:

ghcr.io/jiridanek/notebooks/workbench-images:runtime-minimal-ubi9-python-3.11-jd_reduce_need_for_TESTCONTAINERS_DOCKE_e87244e39784068b4a429e00eca44b1c94253a28

Root Cause: The issue appears to be that either:

1. The fork (jiridanek/notebooks) doesn't have the latest template fixes
2. There's a different workflow or code path not using the template
3. The template logic isn't being applied correctly in some scenarios

Recommendation: Issue #862 should be addressed by ensuring the fork has the latest template fixes and investigating why the length limiting isn't being applied in that specific workflow run.

---

🏁 Script executed:

#!/bin/bash
# Let's check if the error is happening in a fork and whether the fork has the latest fixes
# The error shows "jiridanek/notebooks" which suggests it's a fork

# Let's also simulate what the tag should look like with the fix applied
echo "=== Simulating tag generation with current fix ==="
BRANCH_NAME="jd_reduce_need_for_TESTCONTAINERS_DOCKER_SOCKET_OVERRIDE"
TARGET="runtime-minimal-ubi9-python-3.11"
SHA="e87244e39784068b4a429e00eca44b1c94253a28"

# Apply the sanitization and length limiting from the template
SANITIZED_REF_NAME=$(echo "$BRANCH_NAME" | sed 's/[^a-zA-Z0-9._-]/_/g' | cut -c 1-40)
IMAGE_TAG="${SANITIZED_REF_NAME}_${SHA}"

echo "Original branch name: $BRANCH_NAME ($(echo $BRANCH_NAME | wc -c) chars)"
echo "Sanitized and cut: $SANITIZED_REF_NAME ($(echo $SANITIZED_REF_NAME | wc -c) chars)"
echo "Full image tag: $TARGET-$IMAGE_TAG ($(echo "$TARGET-$IMAGE_TAG" | wc -c) chars)"

# Check if this would fit within limits
FULL_TAG="ghcr.io/jiridanek/notebooks/workbench-images:$TARGET-$IMAGE_TAG"
echo "Complete tag: $FULL_TAG ($(echo $FULL_TAG | wc -c) chars)"

Length of output: 2165

---

🏁 Script executed:

#!/bin/bash
# Let's check the git history to see when these fixes were added and compare with issue dates
echo "=== Checking when the fixes were added ==="
git log --oneline --grep="631" --grep="cut.*ref" --grep="downcase" --since="2025-02-01" | head -10

echo "=== Checking the dates of the template changes ==="
git log --oneline -p --since="2025-02-01" -- .github/workflows/build-notebooks-TEMPLATE.yaml | grep -E "^commit|^\+.*cut -c 1-40|^\+.*IMAGE_REGISTRY.*,," | head -10

Length of output: 205

---

🏁 Script executed:

#!/bin/bash
# Let's check if there might be other workflow files or if the issue occurs in a different context
# Look for any other image tag generation logic outside the template

echo "=== Searching for other tag generation patterns ==="
rg -A 3 -B 3 "IMAGE_TAG.*=|tag.*=.*github\.ref" .github/ --type yaml

echo "=== Looking for any hardcoded tag patterns ==="
rg -A 2 -B 2 "workbench-images:" .github/ --type yaml

Length of output: 1466

---

Based on my analysis, I can now provide a complete answer:

Updated Analysis: The Fix is Implemented but Insufficient

✅ Issue #631 fixes are correctly implemented - the template contains both the lowercase conversion and 40-character branch name limiting.

❌ Issue #862 reveals the fix is mathematically insufficient:

When I simulate the current fix with the actual error case:

• Registry: ghcr.io/jiridanek/notebooks/workbench-images: (45 chars)
• Target: runtime-minimal-ubi9-python-3.11- (35 chars)
• Ref (cut to 40): jd_reduce_need_for_TESTCONTAINERS_DOCKER (40 chars)
• Underscore: _ (1 char)
• SHA: e87244e39784068b4a429e00eca44b1c94253a28 (40 chars)
• Total: 161 chars (still exceeds 128-char limit!)

Root Cause: The template comment assumes target names are "<40 chars" but runtime-minimal-ubi9-python-3.11 is 34 characters. The math should be:

• Fixed parts: 45 + 35 + 1 + 40 = 121 chars
• Available for ref: 128 - 121 = 7 chars maximum

The branch name should be cut to ~7 characters, not 40, for this specific target.

Recommendation: Issue #862 needs a more sophisticated fix that calculates the maximum ref length dynamically based on the actual target name length, rather than using a fixed 40-character limit.

---

🏁 Script executed:

#!/bin/bash
# I need to investigate further - the simulation shows the fix is still insufficient
# Let's break down the tag components to understand the math

echo "=== Analyzing tag component lengths ==="
REGISTRY="ghcr.io/jiridanek/notebooks/workbench-images:"
TARGET="runtime-minimal-ubi9-python-3.11-"
REF_PART="jd_reduce_need_for_TESTCONTAINERS_DOCKER"  # 40 chars after cut
UNDERSCORE="_"
SHA="e87244e39784068b4a429e00eca44b1c94253a28"

echo "Registry part: '$REGISTRY' ($(echo -n "$REGISTRY" | wc -c) chars)"
echo "Target part: '$TARGET' ($(echo -n "$TARGET" | wc -c) chars)"  
echo "Ref part: '$REF_PART' ($(echo -n "$REF_PART" | wc -c) chars)"
echo "Underscore: '$UNDERSCORE' ($(echo -n "$UNDERSCORE" | wc -c) chars)"
echo "SHA part: '$SHA' ($(echo -n "$SHA" | wc -c) chars)"

TOTAL=$(($(echo -n "$REGISTRY" | wc -c) + $(echo -n "$TARGET" | wc -c) + $(echo -n "$REF_PART" | wc -c) + $(echo -n "$UNDERSCORE" | wc -c) + $(echo -n "$SHA" | wc -c)))
echo "Total: $TOTAL chars (limit is 128)"

echo ""
echo "=== Calculating correct ref length for 128 limit ==="
FIXED_PARTS=$(($(echo -n "$REGISTRY" | wc -c) + $(echo -n "$TARGET" | wc -c) + $(echo -n "$UNDERSCORE" | wc -c) + $(echo -n "$SHA" | wc -c)))
MAX_REF_LENGTH=$((128 - $FIXED_PARTS))
echo "Fixed parts total: $FIXED_PARTS chars"  
echo "Maximum ref length should be: $MAX_REF_LENGTH chars (not 40)"

Length of output: 2102

---

🏁 Script executed:

#!/bin/bash
# Let's also check if the error in #862 could be from an older version of the workflow
# by looking at what the URL pattern tells us about the workflow run

echo "=== Analyzing the error context from issue #862 ==="
echo "Error URL: https://github.com/jiridanek/notebooks/actions/runs/12938132231/job/36087687905#step:17:49"
echo "This is from jiridanek's fork, not the main repository"

# Let's check if there might be other places where tags are generated
rg -A 5 -B 5 "docker.*tag|podman.*tag" .github/workflows/ --type yaml

Length of output: 519

---

🏁 Script executed:

#!/bin/bash
# Let's also verify the comment in the template about the math being used
echo "=== Checking the assumption in the template comment ==="
grep -A 5 -B 5 "target names are.*40" .github/workflows/build-notebooks-TEMPLATE.yaml

echo ""
echo "=== Let's verify what the longest target name actually is ==="
find . -name "*.yaml" -path "*/kustomize/*" | head -10 | while read file; do
  if [[ "$file" == *"/base/"* ]]; then
    dir_path=$(dirname "$file")
    target_name=$(echo "$dir_path" | sed 's|.*/\([^/]*\)/kustomize/base$|\1|')
    echo "Target: $target_name ($(echo -n "$target_name" | wc -c) chars)"
  fi
done | sort -k2 -nr | head -5

Length of output: 5965

---

Based on my comprehensive analysis, here's the complete status:

Final Analysis: Implementation Status and Issues

✅ Issue #631 - Correctly Implemented:

• PR ISSUE #631: lowercase the image repository name in github actions #919 (Feb 2025): Added lowercase conversion ✅
• PR Issue opendatahub-io/notebooks#631: cut the ref name to avoid going over 128 character limit for Docker image tag #1027 (Apr 2025): Added 40-character branch name limiting ✅

❌ Issue #862 - Fix is Mathematically Insufficient:

The current fix is implemented but doesn't work correctly due to flawed assumptions. My analysis reveals:

Current Logic (Broken):

# Template assumes: "target names are <40 chars, we should cut ref_name at 40"
SANITIZED_REF_NAME=$(echo "${{ github.ref_name }}" | sed 's/[^a-zA-Z0-9._-]/_/g') | cut -c 1-40

Actual Math for Error Case:

• Registry: ghcr.io/jiridanek/notebooks/workbench-images: (45 chars)
• Target: runtime-minimal-ubi9-python-3.11- (33 chars)
• Ref (cut to 40): jd_reduce_need_for_TESTCONTAINERS_DOCKER (40 chars)
• Underscore + SHA: _e87244e39784068b4a429e00eca44b1c94253a28 (41 chars)
• Total: 159 chars (31 chars over 128 limit!)

Correct Calculation:

For this case, the ref should be limited to 9 characters (128 - 119 = 9), not 40.

Root Cause:

The template's assumption that "target names are <40 chars" is incorrect. The target runtime-minimal-ubi9-python-3.11 is 33 characters, making the fixed 40-character ref limit inadequate.

Solution Needed:

The fix should calculate the maximum ref length dynamically:

Recommendation: Issue #862 needs a new PR to fix the mathematical error in the current implementation.

---

🏁 Script executed:

#!/bin/bash
# Let's get a better understanding of what target names are actually being used in the repository
echo "=== Finding all target names (directory names) ==="
find . -path "*/kustomize/base" | sed 's|/kustomize/base||' | sed 's|.*/||' | sort | uniq -c | sort -nr

echo ""
echo "=== Looking for the runtime-minimal pattern specifically ==="
find . -name "*runtime*" -type d | head -10
rg "runtime-minimal" . --type yaml | head -5

Length of output: 1129

---

🏁 Script executed:

MAX_REF_LENGTH=$((128 - ${#REGISTRY} - ${#TARGET} - 1 - 40))  # 1=underscore, 40=SHA
SANITIZED_REF_NAME=$(echo "$ref_name" | sed 's/[^a-zA-Z0-9._-]/_/g' | cut -c 1-$MAX_REF_LENGTH)

Length of output: 98

---

Based on my thorough analysis, here's the complete implementation status:

✅ Issue #631: Correctly Implemented

The fixes from issue #631 are properly implemented in .github/workflows/build-notebooks-TEMPLATE.yaml:

1. PR ISSUE #631: lowercase the image repository name in github actions #919 (merged Feb 24, 2025): Lowercase conversion ✅
2. PR Issue opendatahub-io/notebooks#631: cut the ref name to avoid going over 128 character limit for Docker image tag #1027 (merged Apr 24, 2025): Branch name limiting ✅

All other workflows correctly use this template via uses: ./.github/workflows/build-notebooks-TEMPLATE.yaml.

❌ Issue #862: Fix is Mathematically Insufficient

While the implementation exists, it doesn't work correctly for longer target names. My analysis reveals:

The Problem:

The template comment states: "target names are <40 chars, we should cut ref_name at 40"

This assumption is wrong. For the failing case:

• Target: runtime-minimal-ubi9-python-3.11 = 33 characters (not <40 as assumed)
• With current 40-char ref limit: 159 total characters (31 over the 128 limit)
• Correct ref limit needed: 9 characters (not 40)

Evidence:

• Most targets: ubi9-python-3.11 (16 chars) - current fix works ✅
• Problem target: runtime-minimal-ubi9-python-3.11 (33 chars) - current fix fails ❌

Solution Required:

Replace the fixed 40-character limit with dynamic calculation:

# Calculate actual available space for ref name
REGISTRY_LEN=$(echo -n "${{ env.IMAGE_REGISTRY }}:" | wc -c)
TARGET_LEN=$(echo -n "${{ inputs.target }}-" | wc -c)
MAX_REF_LEN=$((128 - $REGISTRY_LEN - $TARGET_LEN - 1 - 40))  # 1=underscore, 40=SHA
SANITIZED_REF_NAME=$(echo "${{ github.ref_name }}" | sed 's/[^a-zA-Z0-9._-]/_/g' | cut -c 1-$MAX_REF_LEN)

Recommendation: Issue #862 needs a new PR to fix the mathematical error in the current "solution."

---

🏁 Script executed:

#!/bash/sh
# Let's confirm the target name that's causing the issue by searching for the runtime-minimal targets
echo "=== Finding runtime-minimal targets ==="
find . -path "*runtime*minimal*" -type d | head -5

# Let's see what the build matrix generation looks like to understand how targets are determined
echo ""
echo "=== Checking how targets are generated ==="
rg -A 10 -B 5 "runtime.*minimal" .github/workflows/ --type yaml

Length of output: 2871

---

Perfect! This confirms my analysis. The runtime-minimal-ubi9-python-3.11 target exists in the repository at ./runtimes/minimal/ubi9-python-3.11/ and is listed in the cleanup workflows.

Final Answer: Implementation Status

✅ Issue #631: Implemented but Insufficient

The fixes are implemented in the template workflow:

• Lowercase conversion (PR ISSUE #631: lowercase the image repository name in github actions #919) ✅
• 40-character branch name limiting (PR Issue opendatahub-io/notebooks#631: cut the ref name to avoid going over 128 character limit for Docker image tag #1027) ✅

❌ Issue #862: Reveals Mathematical Error

The implementation is not correct because:

1. Target confirmed: runtime-minimal-ubi9-python-3.11 (33 characters)

2. Math breakdown:

   • Registry: 45 chars
   • Target: 33 chars
   • Current ref limit: 40 chars
   • SHA + underscore: 41 chars
   • Total: 159 chars (31 over 128 limit)

3. Required fix: Dynamic calculation

   MAX_REF_LEN=$((128 - REGISTRY_LEN - TARGET_LEN - 41))  # = 9 chars for this case

Summary

• When transforming branch name into image label while running CI checks, take care not to create invalid label #631 fixes are implemented ✅
• When transforming branch name into image label while running CI checks, take care not to create invalid label #631 fixes are mathematically wrong ❌
• respect the image tag length limit in gha #862 demonstrates the failure ❌
• Dynamic ref length calculation needed 🔧

The template's assumption that "target names are <40 chars" fails for runtime-minimal-* targets, requiring a new PR to fix the mathematical error.

---

✏️ Learnings added

Learnt from: jiridanek
URL: https://github.com/opendatahub-io/notebooks/issues/862

Timestamp: 2025-07-12T20:04:30.983Z
Learning: Issue #862 in opendatahub-io/notebooks reveals that the Docker image tag length fix from issue #631 is mathematically insufficient. While the fix correctly limits branch names to 40 characters, this fails for longer target names like "runtime-minimal-ubi9-python-3.11" (33 chars) which still produces tags exceeding the 128-character Docker limit. The fix needs dynamic calculation based on actual target name length rather than a fixed 40-character assumption.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

---

🧠 Learnings used

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/test/test_notebook.ipynb:22-29
Timestamp: 2025-07-02T18:27:51.097Z
Learning: jiridanek consistently creates comprehensive follow-up GitHub issues from PR review comments in opendatahub-io/notebooks, turning specific code quality concerns into systematic improvements tracked with proper context, acceptance criteria, and cross-references. Issue #1266 demonstrates this pattern by expanding a specific error handling concern in load_expected_versions() into a repository-wide improvement initiative.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-30T19:44:57.656Z
Learning: In the opendatahub-io/notebooks repository, jiridanek effectively manages comprehensive PR reviews by tracking all feedback as follow-up GitHub issues rather than blocking merge of high-quality implementations. This demonstrates excellent project management practices for balancing current deliverables with future improvements.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/nginx/root/usr/share/container-scripts/nginx/common.sh:1-3
Timestamp: 2025-07-03T12:07:19.365Z
Learning: jiridanek consistently requests GitHub issue creation for technical improvements identified during code reviews in opendatahub-io/notebooks, ensuring systematic tracking of code quality enhancements like shell script portability issues with comprehensive descriptions, solution options, and acceptance criteria.

---

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#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Dockerfile.rocm:56-66
Timestamp: 2025-07-02T18:19:49.397Z
Learning: jiridanek consistently creates comprehensive follow-up GitHub issues for security concerns raised during PR reviews in opendatahub-io/notebooks, ensuring systematic tracking and resolution of supply-chain security improvements like GPG signature verification for package repositories.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1151
File: jupyter/tensorflow/ubi9-python-3.12/test/test_notebook.ipynb:31-34
Timestamp: 2025-07-01T07:03:05.385Z
Learning: jiridanek demonstrates excellent pattern recognition for identifying duplicated code issues across the opendatahub-io/notebooks repository. When spotting a potential problem in test notebooks, he correctly assesses that such patterns are likely replicated across multiple similar files rather than being isolated incidents, leading to more effective systematic solutions.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1151
File: jupyter/tensorflow/ubi9-python-3.12/test/test_notebook.ipynb:24-30
Timestamp: 2025-07-01T06:57:26.974Z
Learning: In the opendatahub-io/notebooks repository, jiridanek's team relies on strict CI process enforcement to handle potentially fragile code patterns like hard-coded relative paths. They accept some code fragility when it's mitigated through reliable CI setup and process controls, rather than always requiring code-level fixes.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/test/test_notebook.ipynb:71-76
Timestamp: 2025-07-04T06:04:43.085Z
Learning: jiridanek requested GitHub issue creation for duplicate CSV loading and validation problem in jupyter/trustyai/ubi9-python-3.12/test/test_notebook.ipynb during PR #1306 review. Issue #1322 was created with comprehensive problem description covering code redundancy, runtime failure risks, network inefficiency, and test reliability concerns, along with detailed solution including duplicate line removal, data validation implementation, repository-wide audit, 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/test/test_notebook.ipynb:71-88
Timestamp: 2025-07-04T06:05:30.580Z
Learning: jiridanek requested GitHub issue creation for TrustyAI test notebook URL configurability and network error handling improvements during PR #1306 review. Issue #1323 was created with ⚠️ emoji in title for visibility, comprehensive problem description covering incorrect hardcoded URLs (pointing to Python 3.11 instead of 3.12), missing network error handling, maintenance burden, multiple solution options with code examples, phased acceptance criteria, implementation guidance, testing approach, 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/test/test_notebook.ipynb:112-126
Timestamp: 2025-07-08T13:21:09.150Z
Learning: jiridanek requested GitHub issue creation for notebook linting and formatting improvements during PR #1306 review, specifically to address inconsistent metadata across .ipynb files and implement systematic quality standards. This continues the established pattern of comprehensive issue creation for code quality improvements with detailed problem descriptions, multiple solution options, phased acceptance criteria, and proper context linking.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1230
File: jupyter/minimal/ubi9-python-3.12/Dockerfile.rocm:43-55
Timestamp: 2025-07-01T06:48:21.070Z
Learning: When security concerns are raised during PR reviews in opendatahub-io/notebooks, comprehensive follow-up issues are created (often by CodeRabbit) to track all related security enhancements with clear acceptance criteria and implementation guidance. This ensures security improvements are systematically addressed in dedicated efforts rather than blocking current deliverables.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing `runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml` file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1258
File: codeserver/ubi9-python-3.11/Dockerfile.cpu:55-56
Timestamp: 2025-07-03T08:22:25.348Z
Learning: jiridanek directs security concerns raised during PR reviews to existing comprehensive security issues rather than addressing them in individual PRs. Issue #1241 "Security: Add checksum verification for downloaded binaries in Python 3.12 images" serves as the central tracking issue for all binary download security concerns across the opendatahub-io/notebooks repository.

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/test/test_notebook.ipynb:44-50
Timestamp: 2025-07-03T16:18:59.234Z
Learning: In the opendatahub-io/notebooks repository, the expected_versions.json file referenced in test notebooks (like test_notebook.ipynb) is generated during test execution, not included as a static file in the PR. This is an established testing pattern that should not be flagged as a missing file issue. The pattern is actively managed through issues like #1243 "Improve error handling in get_expected_version() functions across test notebooks" and #1254 "Fix undefined variable error in ROCm PyTorch Python 3.12 test notebook".

---

Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/utils/process.sh:17-19
Timestamp: 2025-07-03T14:00:00.909Z
Learning: jiridanek efficiently identifies when CodeRabbit review suggestions are already covered by existing comprehensive issues, demonstrating excellent issue management and avoiding duplicate tracking of the same improvements across multiple locations.