USHIFT-6716: Add el10 bootc release scenarios#6401
USHIFT-6716: Add el10 bootc release scenarios#6401vanhalenar wants to merge 6 commits intoopenshift:mainfrom
Conversation
|
@vanhalenar: This pull request references USHIFT-6716 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.22.0" version, but no target version was set. DetailsIn response to this: 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 openshift-eng/jira-lifecycle-plugin repository. |
WalkthroughAdds three new containerfile templates for RHEL102 bootc images, ~40 new bootc EL10 scenario scripts (standard, nightly, specialized, multi-config, published-images, and upgrade/LVMS flows), and removes two legacy standard scenario scripts. All additions define scenario entrypoints or image build templates. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: vanhalenar The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
/test ? |
|
/test e2e-aws-tests-bootc-release-el10 |
There was a problem hiding this comment.
Actionable comments posted: 9
🧹 Nitpick comments (1)
test/scenarios-bootc/el10/releases/el102-lrel@ipv6.sh (1)
21-28: Harden restoration ofMIRROR_REGISTRY_URLon early exit.If the function exits between Line 22 and Line 28, the overridden global can leak to later steps. Use a trap for guaranteed restore.
Proposed hardening
- local original_mirror_registry_url="${MIRROR_REGISTRY_URL}" - MIRROR_REGISTRY_URL="$(hostname):${MIRROR_REGISTRY_PORT}/microshift" + local original_mirror_registry_url="${MIRROR_REGISTRY_URL}" + trap 'MIRROR_REGISTRY_URL="${original_mirror_registry_url}"' RETURN + MIRROR_REGISTRY_URL="$(hostname):${MIRROR_REGISTRY_PORT}/microshift" @@ - # Restore original MIRROR_REGISTRY_URL for runtime use - MIRROR_REGISTRY_URL="${original_mirror_registry_url}" + # restored by trap on function return🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/scenarios-bootc/el10/releases/el102-lrel`@ipv6.sh around lines 21 - 28, The MIRROR_REGISTRY_URL override can leak if the script exits early; before setting MIRROR_REGISTRY_URL="$(hostname):${MIRROR_REGISTRY_PORT}/microshift" save the original in original_mirror_registry_url and install a trap on EXIT that restores MIRROR_REGISTRY_URL="${original_mirror_registry_url}" and clears the trap, then call prepare_kickstart (function name) and finally explicitly restore and remove the trap after the call to avoid double-restores—this guarantees the global is restored on any early exit.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@test/image-blueprints-bootc/layer4-release/group1/rhel102-bootc-brew-nightly-with-optional.containerfile`:
- Around line 13-14: The containerfile COPY references
microshift-fast-datapath-rhel9.repo while building an EL10 image; create a
microshift-fast-datapath-rhel10.repo with the EL10 repository definitions and
replace references to microshift-fast-datapath-rhel9.repo in all EL10
containerfiles (or, if reuse is intentional, add documentation/comments
explaining why the EL9 repo is compatible) so that the COPY line and package
streams use an EL10-specific fast-datapath repo.
In `@test/scenarios-bootc/el10/releases/el102-lrel`@fips.sh:
- Around line 7-12: The check_platform function currently hardcodes record_junit
"setup" which misreports skips when invoked from other hooks; modify
check_platform to accept a hook identifier parameter (e.g., check_platform
"$HOOK_NAME") and use that parameter in the record_junit call instead of the
hardcoded "setup", and update all call sites (the places invoking check_platform
from teardown/test hooks) to pass the correct hook string (for example
"teardown" or "test" combined with "scenario_create_vms") so the recorded JUnit
entry matches the actual hook context.
In `@test/scenarios-bootc/el10/releases/el102-lrel`@iso-standard1.sh:
- Line 11: Replace the incorrect use of the source image variable start_image
when calling launch_vm with the intended VM profile name: change the call
launch_vm "${start_image}" --vm_vcpus 4 to launch_vm rhel102-bootc --vm_vcpus 4
so the VM uses the rhel102-bootc profile; apply the same fix in the sibling
script el102-lrel@iso-standard2.sh where launch_vm is passed start_image.
In `@test/scenarios-bootc/el10/releases/el102-lrel`@iso-standard2.sh:
- Line 11: The call to launch_vm is using the source image variable start_image
but must pass the boot blueprint name; change the first argument of launch_vm
from ${start_image} to the boot profile name rhel102-bootc (keeping the existing
--vm_vcpus 4 flag) so launch_vm("rhel102-bootc", ...) is invoked and the correct
target is provisioned.
In `@test/scenarios-bootc/el10/releases/el102-lrel`@multi-config-standard1.sh:
- Around line 21-22: The image-check logic in scenario_create_vms is
inconsistent with the standard2 variant: it calls exit_if_image_not_found (hard
fail) while the other script uses does_image_exist (soft skip); pick the
intended behavior and make both scripts match—either replace
exit_if_image_not_found with does_image_exist in scenario_create_vms to perform
a soft skip, or change the other script to use exit_if_image_not_found for a
hard failure; update the call in scenario_create_vms and any related
documentation/comments so both variants use the same image-checking function
(exit_if_image_not_found or does_image_exist).
In `@test/scenarios-bootc/el10/releases/el102-lrel`@multi-config-standard2.sh:
- Around line 96-102: The comment "Validate LVMS still works after all tests" is
misleading because the run_command_on_vm call to execute
scripts/lvms-helpers/checkWorkloadExists.sh runs before run_tests; either move
the two lines that invoke checkWorkloadExists.sh and cleanupWorkload.sh (the
run_command_on_vm host1 'bash -s' invocations) to after the run_tests invocation
so validation truly occurs post-tests, or update the echo/comment text to
accurately state this is a pre-test validation; locate these calls by the
run_command_on_vm usage and the referenced scripts checkWorkloadExists.sh and
cleanupWorkload.sh and adjust accordingly.
In `@test/scenarios-bootc/el10/releases/el102-lrel`@multi-nic.sh:
- Around line 25-26: The script extracts NIC IPs using head/tail which can pick
the wrong addresses when manage-vm.sh ip returns more or fewer entries; change
the logic that sets vm_ip1 and vm_ip2 to select by interface/network name (e.g.,
call "${ROOTDIR}/scripts/devenv-builder/manage-vm.sh" ip -n "${vmname}" <ifname>
or parse the output to find entries matching the desired interface labels) and
validate the returned list has exactly the expected IPs before calling
run_tests; update the assignments for vm_ip1 and vm_ip2 and add a guard that
errors out with a clear message if the expected addresses are not found for
vmname.
In `@test/scenarios-bootc/el10/releases/el98-lrel`@el102-lrel@standard1.sh:
- Line 17: The VM launch target in the launch_vm invocation is wrong: replace
the image identifier used in the launch_vm command (currently "rhel96-bootc")
with the EL9.8 start image identifier (e.g., "rhel98-bootc") so the VM profile
matches the declared EL9.8 start image; update the single call to launch_vm
rhel96-bootc --vm_vcpus 4 to use the EL9.8 image name instead.
In `@test/scenarios-bootc/el10/releases/el98-lrel`@el102-lrel@standard2.sh:
- Line 17: The launch call uses the wrong base image: replace the launch_vm
invocation that currently specifies "rhel96-bootc" with the EL9.8 base image
"rhel98-bootc" so the scenario tests the correct upgrade path; update the single
invocation of launch_vm (the line containing launch_vm rhel96-bootc) to use
rhel98-bootc.
---
Nitpick comments:
In `@test/scenarios-bootc/el10/releases/el102-lrel`@ipv6.sh:
- Around line 21-28: The MIRROR_REGISTRY_URL override can leak if the script
exits early; before setting
MIRROR_REGISTRY_URL="$(hostname):${MIRROR_REGISTRY_PORT}/microshift" save the
original in original_mirror_registry_url and install a trap on EXIT that
restores MIRROR_REGISTRY_URL="${original_mirror_registry_url}" and clears the
trap, then call prepare_kickstart (function name) and finally explicitly restore
and remove the trap after the call to avoid double-restores—this guarantees the
global is restored on any early exit.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
Run ID: 234be6cf-4d6a-4d72-8261-a0a977b95f69
📒 Files selected for processing (29)
test/image-blueprints-bootc/layer4-release/group1/rhel102-bootc-brew-nightly-with-optional.containerfiletest/image-blueprints-bootc/layer4-release/group2/rhel102-bootc-brew-lrel-fips.containerfiletest/image-blueprints-bootc/layer4-release/group2/rhel102-bootc-brew-lrel-tuned.containerfiletest/scenarios-bootc/el10/releases/el102-lrel@ai-model-serving-online.shtest/scenarios-bootc/el10/releases/el102-lrel@configuration.shtest/scenarios-bootc/el10/releases/el102-lrel@dual-stack.shtest/scenarios-bootc/el10/releases/el102-lrel@fips.shtest/scenarios-bootc/el10/releases/el102-lrel@ipv6.shtest/scenarios-bootc/el10/releases/el102-lrel@iso-standard1.shtest/scenarios-bootc/el10/releases/el102-lrel@iso-standard2.shtest/scenarios-bootc/el10/releases/el102-lrel@low-latency.shtest/scenarios-bootc/el10/releases/el102-lrel@multi-config-standard1.shtest/scenarios-bootc/el10/releases/el102-lrel@multi-config-standard2.shtest/scenarios-bootc/el10/releases/el102-lrel@multi-nic.shtest/scenarios-bootc/el10/releases/el102-lrel@nightly-brew-standard1.shtest/scenarios-bootc/el10/releases/el102-lrel@nightly-brew-standard2.shtest/scenarios-bootc/el10/releases/el102-lrel@osconfig-router.shtest/scenarios-bootc/el10/releases/el102-lrel@published-images-standard1.shtest/scenarios-bootc/el10/releases/el102-lrel@published-images-standard2.shtest/scenarios-bootc/el10/releases/el102-lrel@standard1.shtest/scenarios-bootc/el10/releases/el102-lrel@standard2.shtest/scenarios-bootc/el10/releases/el102-lrel@storage-telemetry.shtest/scenarios-bootc/el10/releases/el102-lrel@tlsv13-standard1.shtest/scenarios-bootc/el10/releases/el96-y2@el102-lrel@lvms.shtest/scenarios-bootc/el10/releases/el96-y2@el102-lrel@standard1.shtest/scenarios-bootc/el10/releases/el96-y2@el102-lrel@standard2.shtest/scenarios-bootc/el10/releases/el98-lrel@el102-lrel@lvms.shtest/scenarios-bootc/el10/releases/el98-lrel@el102-lrel@standard1.shtest/scenarios-bootc/el10/releases/el98-lrel@el102-lrel@standard2.sh
💤 Files with no reviewable changes (2)
- test/scenarios-bootc/el10/releases/el102-lrel@standard2.sh
- test/scenarios-bootc/el10/releases/el102-lrel@standard1.sh
...lueprints-bootc/layer4-release/group1/rhel102-bootc-brew-nightly-with-optional.containerfile
Show resolved
Hide resolved
test/scenarios-bootc/el10/releases/el98-lrel@el102-lrel@standard1.sh
Outdated
Show resolved
Hide resolved
test/scenarios-bootc/el10/releases/el98-lrel@el102-lrel@standard2.sh
Outdated
Show resolved
Hide resolved
|
/test e2e-aws-tests-bootc-release-el10 |
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@test/scenarios-bootc/el10/releases/el102-lrel`@tlsv13-standard2.sh:
- Around line 14-18: The teardown function scenario_remove_vms should not be
gated by registry/image checks: remove or relocate the call to
exit_if_image_not_found so it cannot prevent remove_vm host1 from running;
specifically, either delete the exit_if_image_not_found "${start_image}" line
from scenario_remove_vms or change it to a non-fatal check/log (e.g., warn) so
that remove_vm host1 always executes to avoid leaked VMs.
In `@test/scenarios-bootc/el10/releases/el96-y1`@el102-lrel@lvms.sh:
- Around line 20-23: The teardown function scenario_remove_vms currently calls
exit_if_image_not_found("${start_image}") and
exit_if_image_not_found("${dest_image}") which can abort the teardown and leave
host1 running; change the logic so image-not-found checks do not call exit
during teardown (either remove these exit_* calls from scenario_remove_vms or
replace them with non-fatal checks that log a warning), and ensure remove_vm
host1 is always executed unconditionally at the end of scenario_remove_vms so
the VM is always cleaned up even if image lookups fail.
- Around line 42-55: The retry counter `iter` in checkLvmsResources.sh is
initialized once before the "for pod in" loop so all pods share retries; move
the initialization (iter=24) inside the loop so each pod starts with its own
retry budget, i.e., locate the "for pod in" loop in checkLvmsResources.sh and
add/reset iter=24 at the top of that loop body (before the per-pod retry/wait
logic) to ensure each pod gets independent retries.
In `@test/scenarios-bootc/el10/releases/el96-y1`@el102-lrel@standard1.sh:
- Around line 20-25: The teardown function scenario_remove_vms must not abort
based on image lookup; remove or relocate the exit_if_image_not_found calls so
VM cleanup always runs — ensure scenario_remove_vms calls remove_vm host1
unconditionally (or only guards that don't call exit), and if image validation
is still needed keep it in setup code instead of inside scenario_remove_vms.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
Run ID: d1b8e79b-c036-4cd6-bd7a-d86c3d378d48
📒 Files selected for processing (6)
test/scenarios-bootc/el10/releases/el102-lrel@tlsv13-standard2.shtest/scenarios-bootc/el10/releases/el96-y1@el102-lrel@lvms.shtest/scenarios-bootc/el10/releases/el96-y1@el102-lrel@standard1.shtest/scenarios-bootc/el10/releases/el96-y1@el102-lrel@standard2.shtest/scenarios-bootc/el10/releases/el98-lrel@el102-lrel@standard1.shtest/scenarios-bootc/el10/releases/el98-lrel@el102-lrel@standard2.sh
🚧 Files skipped from review as they are similar to previous changes (2)
- test/scenarios-bootc/el10/releases/el98-lrel@el102-lrel@standard1.sh
- test/scenarios-bootc/el10/releases/el98-lrel@el102-lrel@standard2.sh
|
/test e2e-aws-tests-bootc-release-el10 |
|
/retest |
|
/test e2e-aws-tests-bootc-arm-el9 |
|
/test e2e-aws-tests-bootc-release-el10 Added by microshift-prow-jobs-for-pull-requests.sh 🤖 |
f8774b2 to
8286617
Compare
|
/test e2e-aws-tests-bootc-release-el10 |
There was a problem hiding this comment.
Actionable comments posted: 8
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@test/image-blueprints-bootc/layer4-release/group1/rhel102-bootc-brew-nightly-with-optional.containerfile`:
- Around line 6-10: The ARG USHIFT_RPM_REPO_PATH=/tmp/$USHIFT_RPM_REPO_NAME does
not expand and will be literal; replace usages by either defining the path with
an ENV that expands (e.g. ENV USHIFT_RPM_REPO_PATH=/tmp/$USHIFT_RPM_REPO_NAME)
or avoid the ARG entirely and use the expanded variable directly in COPY and
cleanup commands (e.g. COPY ./rpm-repos/${USHIFT_RPM_REPO_NAME}
/tmp/${USHIFT_RPM_REPO_NAME}) so that the COPY (symbol: COPY) and the later
cleanup lines that reference USHIFT_RPM_REPO_PATH target the actual
/tmp/microshift-brew directory instead of a literal $USHIFT_RPM_REPO_NAME
string.
- Around line 20-29: The templated RPM ranges (MICROSHIFT_MANDATORY_RPMS,
MICROSHIFT_OPTIONAL_RPMS, MICROSHIFT_X86_64_RPMS) can emit empty tokens when
splitting by space, producing invalid items like "-{{ env.Getenv
"BREW_NIGHTLY_RELEASE_VERSION" }}"; inside each range (the {{ range (env.Getenv
"...") | strings.Split " " -}} blocks) guard the iteration by wrapping the
emitted line with a conditional check (e.g. {{ if ne . "" }} ... {{ end }}) so
only non-empty entries produce the "{{ . }}-{{ env.Getenv
"BREW_NIGHTLY_RELEASE_VERSION" }}" output, and apply this to all three ranges
including the x86_64 branch.
In
`@test/image-blueprints-bootc/layer4-release/group2/rhel102-bootc-brew-lrel-tuned.containerfile`:
- Line 17: The tuned profile currently hard-codes CPU sets via
reservedSystemCPUs (= 0-1) and the other entries on lines 39-43; replace these
fixed topology values with configurable variables (e.g., ARG or ENV placeholders
such as RESERVED_SYSTEM_CPUS, KUBELET_CPUS, RT_CPUS) and use those placeholders
in the tuned containerfile so the values can be supplied per-scenario; if
possible provide a safe default that auto-computes based on detected CPU count
(or leaves the field empty) to avoid assuming specific core layouts, and update
the containerfile’s ARG/ENV documentation so callers can supply the correct
CPU-set strings for different instance sizes.
In `@test/scenarios-bootc/el10/releases/el102-lrel`@ipv6.sh:
- Around line 14-30: The preflight currently validates "${start_image}" via
exit_if_image_not_found but then calls launch_vm with a hardcoded VM name
"rhel102-bootc", so a missing VM image there will only fail at launch; add a
check before launch_vm to validate the actual image/name used by launch_vm
(either call exit_if_image_not_found "rhel102-bootc" or replace the literal with
a variable like vm_image and validate exit_if_image_not_found "${vm_image}") so
the precheck aligns with launch_vm.
- Around line 33-36: The cleanup function scenario_remove_vms currently calls
exit_if_image_not_found which can abort the function before remove_vm host1
runs; change the flow so VM cleanup always runs even if the image check
fails—either move remove_vm host1 before calling exit_if_image_not_found, or
replace the fatal helper with a non-fatal check (e.g., warn_if_image_not_found
or an if/else that logs but does not exit) inside scenario_remove_vms so that
remove_vm host1 is executed on cleanup regardless of image lookup result.
In `@test/scenarios-bootc/el10/releases/el102-lrel`@multi-config-standard2.sh:
- Around line 22-35: The precheck validates "${start_image}" but the VM is
launched as "rhel102-bootc", causing a mismatch; update the precheck to validate
the same image used by launch_vm by either calling exit_if_image_not_found with
the image identifier passed to launch_vm (ensure the same variable is used) or
set start_image to the image variable/name used in launch_vm so
exit_if_image_not_found and launch_vm reference the identical symbol
(references: exit_if_image_not_found, start_image, launch_vm rhel102-bootc).
- Around line 38-41: The teardown function scenario_remove_vms currently calls
exit_if_image_not_found "${start_image}" which can abort and prevent remove_vm
host1 from running; change scenario_remove_vms so teardown is best-effort by
removing the exit_if_image_not_found call (or moving that image existence check
to setup code) and always invoking remove_vm host1 (and any other teardown
actions) regardless of image availability; update references in the file to keep
image validation only in setup paths, not in scenario_remove_vms.
In `@test/scenarios-bootc/el10/releases/el102-lrel`@storage-telemetry.sh:
- Around line 23-28: The telemetry run invocation using the run_tests host1 call
passes PROXY_HOST, PROXY_PORT and PROMETHEUS_HOST but omits PROMETHEUS_PORT
which telemetry.robot expects non-empty; update the run_tests call (the
run_tests host1 invocation) to include --variable
"PROMETHEUS_PORT:<port_or_env_value>" alongside the existing variables so
telemetry.robot receives a non-empty PROMETHEUS_PORT (use the proper port value
or substitute an env var like ${PROMETHEUS_PORT} consistent with how
PROXY_HOST/PROXY_PORT are provided).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
Run ID: ec77d69b-b688-4709-a386-a803f366c75b
📒 Files selected for processing (33)
test/image-blueprints-bootc/layer4-release/group1/rhel102-bootc-brew-nightly-with-optional.containerfiletest/image-blueprints-bootc/layer4-release/group2/rhel102-bootc-brew-lrel-fips.containerfiletest/image-blueprints-bootc/layer4-release/group2/rhel102-bootc-brew-lrel-tuned.containerfiletest/scenarios-bootc/el10/releases/el102-lrel@ai-model-serving-online.shtest/scenarios-bootc/el10/releases/el102-lrel@configuration.shtest/scenarios-bootc/el10/releases/el102-lrel@dual-stack.shtest/scenarios-bootc/el10/releases/el102-lrel@fips.shtest/scenarios-bootc/el10/releases/el102-lrel@ipv6.shtest/scenarios-bootc/el10/releases/el102-lrel@iso-standard1.shtest/scenarios-bootc/el10/releases/el102-lrel@iso-standard2.shtest/scenarios-bootc/el10/releases/el102-lrel@low-latency.shtest/scenarios-bootc/el10/releases/el102-lrel@multi-config-standard1.shtest/scenarios-bootc/el10/releases/el102-lrel@multi-config-standard2.shtest/scenarios-bootc/el10/releases/el102-lrel@multi-nic.shtest/scenarios-bootc/el10/releases/el102-lrel@nightly-brew-standard1.shtest/scenarios-bootc/el10/releases/el102-lrel@nightly-brew-standard2.shtest/scenarios-bootc/el10/releases/el102-lrel@osconfig-router.shtest/scenarios-bootc/el10/releases/el102-lrel@published-images-standard1.shtest/scenarios-bootc/el10/releases/el102-lrel@published-images-standard2.shtest/scenarios-bootc/el10/releases/el102-lrel@standard1.shtest/scenarios-bootc/el10/releases/el102-lrel@standard2.shtest/scenarios-bootc/el10/releases/el102-lrel@storage-telemetry.shtest/scenarios-bootc/el10/releases/el102-lrel@tlsv13-standard1.shtest/scenarios-bootc/el10/releases/el102-lrel@tlsv13-standard2.shtest/scenarios-bootc/el10/releases/el96-y1@el102-lrel@lvms.shtest/scenarios-bootc/el10/releases/el96-y1@el102-lrel@standard1.shtest/scenarios-bootc/el10/releases/el96-y1@el102-lrel@standard2.shtest/scenarios-bootc/el10/releases/el96-y2@el102-lrel@lvms.shtest/scenarios-bootc/el10/releases/el96-y2@el102-lrel@standard1.shtest/scenarios-bootc/el10/releases/el96-y2@el102-lrel@standard2.shtest/scenarios-bootc/el10/releases/el98-lrel@el102-lrel@lvms.shtest/scenarios-bootc/el10/releases/el98-lrel@el102-lrel@standard1.shtest/scenarios-bootc/el10/releases/el98-lrel@el102-lrel@standard2.sh
💤 Files with no reviewable changes (2)
- test/scenarios-bootc/el10/releases/el102-lrel@standard2.sh
- test/scenarios-bootc/el10/releases/el102-lrel@standard1.sh
✅ Files skipped from review due to trivial changes (12)
- test/image-blueprints-bootc/layer4-release/group2/rhel102-bootc-brew-lrel-fips.containerfile
- test/scenarios-bootc/el10/releases/el102-lrel@nightly-brew-standard1.sh
- test/scenarios-bootc/el10/releases/el102-lrel@iso-standard1.sh
- test/scenarios-bootc/el10/releases/el102-lrel@nightly-brew-standard2.sh
- test/scenarios-bootc/el10/releases/el102-lrel@configuration.sh
- test/scenarios-bootc/el10/releases/el98-lrel@el102-lrel@standard1.sh
- test/scenarios-bootc/el10/releases/el102-lrel@osconfig-router.sh
- test/scenarios-bootc/el10/releases/el102-lrel@tlsv13-standard2.sh
- test/scenarios-bootc/el10/releases/el102-lrel@fips.sh
- test/scenarios-bootc/el10/releases/el102-lrel@ai-model-serving-online.sh
- test/scenarios-bootc/el10/releases/el102-lrel@dual-stack.sh
- test/scenarios-bootc/el10/releases/el102-lrel@published-images-standard1.sh
🚧 Files skipped from review as they are similar to previous changes (13)
- test/scenarios-bootc/el10/releases/el102-lrel@iso-standard2.sh
- test/scenarios-bootc/el10/releases/el102-lrel@multi-nic.sh
- test/scenarios-bootc/el10/releases/el96-y2@el102-lrel@lvms.sh
- test/scenarios-bootc/el10/releases/el96-y2@el102-lrel@standard2.sh
- test/scenarios-bootc/el10/releases/el102-lrel@tlsv13-standard1.sh
- test/scenarios-bootc/el10/releases/el96-y2@el102-lrel@standard1.sh
- test/scenarios-bootc/el10/releases/el98-lrel@el102-lrel@standard2.sh
- test/scenarios-bootc/el10/releases/el96-y1@el102-lrel@lvms.sh
- test/scenarios-bootc/el10/releases/el102-lrel@low-latency.sh
- test/scenarios-bootc/el10/releases/el102-lrel@published-images-standard2.sh
- test/scenarios-bootc/el10/releases/el102-lrel@multi-config-standard1.sh
- test/scenarios-bootc/el10/releases/el96-y1@el102-lrel@standard1.sh
- test/scenarios-bootc/el10/releases/el98-lrel@el102-lrel@lvms.sh
| ARG USHIFT_RPM_REPO_NAME=microshift-brew | ||
| ARG USHIFT_RPM_REPO_PATH=/tmp/$USHIFT_RPM_REPO_NAME | ||
|
|
||
| # Copy the MicroShift repository contents | ||
| COPY ./rpm-repos/$USHIFT_RPM_REPO_NAME $USHIFT_RPM_REPO_PATH |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat test/image-blueprints-bootc/layer4-release/group1/rhel102-bootc-brew-nightly-with-optional.containerfileRepository: openshift/microshift
Length of output: 2475
🌐 Web query:
Dockerfile ARG expansion nested variable substitution semantics
💡 Result:
Dockerfile ARG expansion does not support nested or recursive variable substitution. Variable substitution using
Citations:
- 1: https://docs.docker.com/build/building/variables
- 2: https://docs.docker.com/reference/dockerfile
- 3: Full support for parameter expansion moby/moby#41383
- 4: https://stackoverflow.com/questions/50239236/dockerfile-arg-substitution-in-a-string-in-run-command
- 5: https://docs.docker.com/reference/compose-file/interpolation
- 6: BUG: Docker ARG command fails to perform argument substitution in recent buildkit versions moby/buildkit#5178
- 7: dockerfile: avoid ignoring errors global arg expansion moby/buildkit#4856
- 8: Restore env replacement process of ARG's variable names moby/buildkit#5156
USHIFT_RPM_REPO_PATH will expand to a literal path, not the intended directory.
Dockerfile does not support nested variable expansion in ARG values. Line 7's ARG USHIFT_RPM_REPO_PATH=/tmp/$USHIFT_RPM_REPO_NAME stores the literal string /tmp/$USHIFT_RPM_REPO_NAME rather than /tmp/microshift-brew. This causes COPY on line 10 and the cleanup on line 34 to target the wrong location.
Proposed fix
ARG USHIFT_RPM_REPO_NAME=microshift-brew
-ARG USHIFT_RPM_REPO_PATH=/tmp/$USHIFT_RPM_REPO_NAME
# Copy the MicroShift repository contents
-COPY ./rpm-repos/$USHIFT_RPM_REPO_NAME $USHIFT_RPM_REPO_PATH
+COPY ./rpm-repos/${USHIFT_RPM_REPO_NAME} /tmp/${USHIFT_RPM_REPO_NAME}- rm -rvf $USHIFT_RPM_REPO_PATH && \
+ rm -rvf /tmp/${USHIFT_RPM_REPO_NAME} && \Also applies to: 33-34
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@test/image-blueprints-bootc/layer4-release/group1/rhel102-bootc-brew-nightly-with-optional.containerfile`
around lines 6 - 10, The ARG USHIFT_RPM_REPO_PATH=/tmp/$USHIFT_RPM_REPO_NAME
does not expand and will be literal; replace usages by either defining the path
with an ENV that expands (e.g. ENV
USHIFT_RPM_REPO_PATH=/tmp/$USHIFT_RPM_REPO_NAME) or avoid the ARG entirely and
use the expanded variable directly in COPY and cleanup commands (e.g. COPY
./rpm-repos/${USHIFT_RPM_REPO_NAME} /tmp/${USHIFT_RPM_REPO_NAME}) so that the
COPY (symbol: COPY) and the later cleanup lines that reference
USHIFT_RPM_REPO_PATH target the actual /tmp/microshift-brew directory instead of
a literal $USHIFT_RPM_REPO_NAME string.
| {{ range (env.Getenv "MICROSHIFT_MANDATORY_RPMS" | strings.Split " ") -}} | ||
| "{{ . }}-{{ env.Getenv "BREW_NIGHTLY_RELEASE_VERSION" }}" \ | ||
| {{ end -}} | ||
| {{ range (env.Getenv "MICROSHIFT_OPTIONAL_RPMS" | strings.Split " ") -}} | ||
| "{{ . }}-{{ env.Getenv "BREW_NIGHTLY_RELEASE_VERSION" }}" \ | ||
| {{ end -}} | ||
| {{ if and (env.Getenv "UNAME_M" "") (eq "x86_64" .Env.UNAME_M) -}} | ||
| {{ range (env.Getenv "MICROSHIFT_X86_64_RPMS" | strings.Split " ") -}} | ||
| "{{ . }}-{{ env.Getenv "BREW_NIGHTLY_RELEASE_VERSION" }}" \ | ||
| {{ end -}} |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n test/image-blueprints-bootc/layer4-release/group1/rhel102-bootc-brew-nightly-with-optional.containerfile | head -40Repository: openshift/microshift
Length of output: 2095
🏁 Script executed:
# Check if this is a Go template or another template engine
file test/image-blueprints-bootc/layer4-release/group1/rhel102-bootc-brew-nightly-with-optional.containerfileRepository: openshift/microshift
Length of output: 108
🏁 Script executed:
# Search for other similar patterns in the codebase to understand the template engine
rg "strings\.Split" --type containerfile -A 2 -B 2Repository: openshift/microshift
Length of output: 101
🏁 Script executed:
# Search for strings.Split usage across the codebase
rg "strings\.Split" -A 2 -B 2 | head -50Repository: openshift/microshift
Length of output: 5241
🏁 Script executed:
# Look for template engine configuration or usage
rg -l "\.containerfile" | head -20Repository: openshift/microshift
Length of output: 145
🏁 Script executed:
# Check if this is a standard Go template by looking for template engine info
find . -name "*.md" -o -name "*.go" | xargs grep -l "containerfile\|template" 2>/dev/null | head -10Repository: openshift/microshift
Length of output: 486
🏁 Script executed:
# Look for build scripts that process these files
find . -name "*.py" -o -name "*.sh" | xargs grep -l "containerfile\|template" 2>/dev/null | head -5Repository: openshift/microshift
Length of output: 425
🏁 Script executed:
# Check the README for bootc images
cat test/README.md | grep -A 20 -B 5 "containerfile\|template" | head -60Repository: openshift/microshift
Length of output: 2259
🏁 Script executed:
# Look for any documentation about the template format
rg "strings\.Split" -B 20 | grep -i "template\|engine\|golang" | head -20Repository: openshift/microshift
Length of output: 2771
🏁 Script executed:
cat test/bin/build_images.sh | head -100Repository: openshift/microshift
Length of output: 4061
🏁 Script executed:
# Search for how containerfiles are processed
rg "containerfile" test/bin/ -A 5 -B 5Repository: openshift/microshift
Length of output: 8759
🏁 Script executed:
# Find the run_template_cmd function
rg "def run_template_cmd" test/bin/pyutils/build_bootc_images.py -A 15Repository: openshift/microshift
Length of output: 562
🏁 Script executed:
# Check what GOMPLATE is
rg "GOMPLATE" test/bin/ -B 5 -A 5Repository: openshift/microshift
Length of output: 6728
🏁 Script executed:
# Check gomplate documentation or examples in the codebase
rg "strings\." test/ -B 3 -A 3 | head -80Repository: openshift/microshift
Length of output: 7335
🌐 Web query:
gomplate strings.Split empty strings behavior
💡 Result:
Gomplate's strings.Split function handles empty strings as follows: - If both the input and separator are empty (strings.Split "" ""), it returns an empty slice. - If the separator is empty, it splits the input after each UTF-8 sequence. - If the input does not contain the separator and the separator is not empty, it returns a single-element slice containing the input. - This matches Go's strings.Split behavior and is equivalent to strings.SplitN with count = -1. The delimiter is not included in the resulting elements. Added in gomplate v1.9.0.
Citations:
- 1: https://docs.gomplate.ca/functions/strings/
- 2: https://github.com/hairyhenderson/gomplate/blob/master/docs/content/functions/strings.md
🏁 Script executed:
# Check if the proposed guard syntax is used anywhere in the codebase
rg "if ne" test/image-blueprints* -A 2 -B 2Repository: openshift/microshift
Length of output: 46
🏁 Script executed:
# Look for other patterns that might have the same issue
rg "strings\.Split" test/image-blueprints-bootc/ -B 2 -A 2 | grep -A 5 -B 5 "range"Repository: openshift/microshift
Length of output: 28299
🌐 Web query:
gomplate template if ne syntax validation
💡 Result:
In gomplate templates, which use Go's text/template syntax, if ne uses the built-in ne comparison function (not equal, equivalent to !=) within an if action for conditional logic. Syntax: {{if ne ARG1 ARG2}} content {{end}} - ne takes exactly two arguments of comparable types (e.g., strings, numbers). Mismatched types or invalid comparisons (like null vs string in older versions) cause errors. - The if evaluates the pipeline; if true (non-empty/non-false), it renders the content between if and end. - Use parentheses for grouping: {{if ne (print .Value) "default"}}. Example checking if a datasource value is not empty: {{ $input := (datasource "user").key }} {{ if ne $input "" }} Value is: {{ $input }} {{ else }} No value provided. {{ end }} Validation notes: - Requires 2 args: {{if ne .Value "foo"}} is valid; single arg fails. - Type-safe: ne "string" 123 errors. - For null safety, use or default: {{if ne (or .Key "") ""}}. - Whitespace trimming: {{- if ne .Value "" -}} suppresses newlines. Gomplate docs confirm ne as built-in operator alongside eq, lt, etc. Go template docs specify prefix notation and comparable types requirement.
Citations:
- 1: https://docs.gomplate.ca/syntax/
- 2: https://docs.gomplate.ca/functions/
- 3: http://docs.gomplate.ca/functions/
- 4: https://stackoverflow.com/questions/63185121/how-do-the-if-and-ne-operators-work-in-helm
- 5: https://app.studyraid.com/en/read/15258/528802/comparison-operators-in-templates
- 6: https://pkg.go.dev/text/template@go1.19
- 7: Allow ne to be used to compare null against a string hairyhenderson/gomplate#693
- 8: https://stackoverflow.com/questions/36209677/how-can-i-conditionally-set-a-variable-in-a-go-template-based-on-an-expression-w
Guard the templated RPM lists against blank entries.
Lines 20–29 use strings.Split " ", which preserves empty tokens. If MICROSHIFT_OPTIONAL_RPMS is empty or has repeated/trimmed spaces, the template emits "-{{ env.Getenv "BREW_NIGHTLY_RELEASE_VERSION" }}", breaking dnf install.
Wrap each range with {{if ne . ""}} to skip empty values. Apply to all three ranges: MANDATORY_RPMS, OPTIONAL_RPMS, and X86_64_RPMS.
Proposed fix
- {{ range (env.Getenv "MICROSHIFT_OPTIONAL_RPMS" | strings.Split " ") -}}
- "{{ . }}-{{ env.Getenv "BREW_NIGHTLY_RELEASE_VERSION" }}" \
- {{ end -}}
+ {{ range (env.Getenv "MICROSHIFT_OPTIONAL_RPMS" | strings.Split " ") -}}
+ {{- if ne . "" }}
+ "{{ . }}-{{ env.Getenv "BREW_NIGHTLY_RELEASE_VERSION" }}" \
+ {{- end }}
+ {{ end -}}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@test/image-blueprints-bootc/layer4-release/group1/rhel102-bootc-brew-nightly-with-optional.containerfile`
around lines 20 - 29, The templated RPM ranges (MICROSHIFT_MANDATORY_RPMS,
MICROSHIFT_OPTIONAL_RPMS, MICROSHIFT_X86_64_RPMS) can emit empty tokens when
splitting by space, producing invalid items like "-{{ env.Getenv
"BREW_NIGHTLY_RELEASE_VERSION" }}"; inside each range (the {{ range (env.Getenv
"...") | strings.Split " " -}} blocks) guard the iteration by wrapping the
emitted line with a conditional check (e.g. {{ if ne . "" }} ... {{ end }}) so
only non-empty entries produce the "{{ . }}-{{ env.Getenv
"BREW_NIGHTLY_RELEASE_VERSION" }}" output, and apply this to all three ranges
including the x86_64 branch.
| cpuManagerReconcilePeriod: 5s | ||
| memoryManagerPolicy: Static | ||
| topologyManagerPolicy: single-numa-node | ||
| reservedSystemCPUs: 0-1 |
There was a problem hiding this comment.
Avoid fixed CPU topology in this tuned image
Line 17 and Lines 39-43 hard-code CPU sets (0-1, 2,4-5, 3), which assumes a specific host core layout. That makes these release scenarios fragile on different instance sizes/topologies and can break tuned/kubelet startup.
Proposed refactor (make CPU sets scenario-configurable)
- reservedSystemCPUs: 0-1
+ reservedSystemCPUs: {{ env.Getenv "LREL_RESERVED_SYSTEM_CPUS" "0-1" }}
@@
-isolated_cores=2,4-5
+isolated_cores={{ env.Getenv "LREL_ISOLATED_CORES" "2,4-5" }}
@@
-offline_cpu_set=3
+offline_cpu_set={{ env.Getenv "LREL_OFFLINE_CPU_SET" "3" }}As per coding guidelines, "Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity."
Also applies to: 39-43
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@test/image-blueprints-bootc/layer4-release/group2/rhel102-bootc-brew-lrel-tuned.containerfile`
at line 17, The tuned profile currently hard-codes CPU sets via
reservedSystemCPUs (= 0-1) and the other entries on lines 39-43; replace these
fixed topology values with configurable variables (e.g., ARG or ENV placeholders
such as RESERVED_SYSTEM_CPUS, KUBELET_CPUS, RT_CPUS) and use those placeholders
in the tuned containerfile so the values can be supplied per-scenario; if
possible provide a safe default that auto-computes based on detected CPU count
(or leaves the field empty) to avoid assuming specific core layouts, and update
the containerfile’s ARG/ENV documentation so callers can supply the correct
CPU-set strings for different instance sizes.
| exit_if_image_not_found "${start_image}" | ||
|
|
||
| # Using `hostname` here instead of a raw ip because skopeo only allows either | ||
| # ipv4 or fqdn's, but not ipv6. Since the registry is hosted on the ipv6 | ||
| # network gateway in the host, we need to use a combination of the hostname | ||
| # plus /etc/hosts resolution (which is taken care of by kickstart). | ||
| # Save the original value and temporarily override for prepare_kickstart | ||
| local original_mirror_registry_url="${MIRROR_REGISTRY_URL}" | ||
| MIRROR_REGISTRY_URL="$(hostname):${MIRROR_REGISTRY_PORT}/microshift" | ||
|
|
||
| # Enable IPv6 single stack in kickstart | ||
| prepare_kickstart host1 kickstart-bootc.ks.template "${start_image}" false true | ||
|
|
||
| # Restore original MIRROR_REGISTRY_URL for runtime use | ||
| MIRROR_REGISTRY_URL="${original_mirror_registry_url}" | ||
|
|
||
| launch_vm rhel102-bootc --network "${VM_IPV6_NETWORK}" --vm_vcpus 4 |
There was a problem hiding this comment.
Align preflight validation with the boot blueprint used by launch_vm.
Line 14 validates ${start_image}, but Line 30 boots rhel102-bootc. If rhel102-bootc is missing, the precheck passes and failure happens later at launch.
As per coding guidelines, "-Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/scenarios-bootc/el10/releases/el102-lrel`@ipv6.sh around lines 14 - 30,
The preflight currently validates "${start_image}" via exit_if_image_not_found
but then calls launch_vm with a hardcoded VM name "rhel102-bootc", so a missing
VM image there will only fail at launch; add a check before launch_vm to
validate the actual image/name used by launch_vm (either call
exit_if_image_not_found "rhel102-bootc" or replace the literal with a variable
like vm_image and validate exit_if_image_not_found "${vm_image}") so the
precheck aligns with launch_vm.
| scenario_remove_vms() { | ||
| exit_if_image_not_found "${start_image}" | ||
|
|
||
| remove_vm host1 |
There was a problem hiding this comment.
Do not block VM cleanup on image lookup.
Line 34 can abort cleanup before remove_vm host1. Cleanup paths should run even when image checks fail, to avoid leaked VMs after partial failures.
Suggested change
scenario_remove_vms() {
- exit_if_image_not_found "${start_image}"
-
remove_vm host1
}As per coding guidelines, "-Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity."
📝 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.
| scenario_remove_vms() { | |
| exit_if_image_not_found "${start_image}" | |
| remove_vm host1 | |
| scenario_remove_vms() { | |
| remove_vm host1 |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/scenarios-bootc/el10/releases/el102-lrel`@ipv6.sh around lines 33 - 36,
The cleanup function scenario_remove_vms currently calls exit_if_image_not_found
which can abort the function before remove_vm host1 runs; change the flow so VM
cleanup always runs even if the image check fails—either move remove_vm host1
before calling exit_if_image_not_found, or replace the fatal helper with a
non-fatal check (e.g., warn_if_image_not_found or an if/else that logs but does
not exit) inside scenario_remove_vms so that remove_vm host1 is executed on
cleanup regardless of image lookup result.
| exit_if_image_not_found "${start_image}" | ||
|
|
||
| # Temporarily override MIRROR_REGISTRY_URL for kickstart preparation | ||
| # The kickstart template needs a hostname-based URL, not an IPv6 address | ||
| local original_mirror_url="${MIRROR_REGISTRY_URL}" | ||
| MIRROR_REGISTRY_URL="$(hostname):${MIRROR_REGISTRY_PORT}/microshift" | ||
|
|
||
| # Enable IPv6 single stack in kickstart, with tuned configuration enabled | ||
| prepare_kickstart host1 kickstart-bootc.ks.template "${start_image}" false true | ||
|
|
||
| # Restore original MIRROR_REGISTRY_URL for runtime use | ||
| MIRROR_REGISTRY_URL="${original_mirror_url}" | ||
|
|
||
| launch_vm rhel102-bootc --network "${VM_IPV6_NETWORK}" --vm_vcpus 6 |
There was a problem hiding this comment.
Precheck and boot artifact are inconsistent.
Line 22 checks ${start_image}, but Line 35 launches rhel102-bootc. This weakens early validation and can surface failures only at VM launch time.
As per coding guidelines, "-Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/scenarios-bootc/el10/releases/el102-lrel`@multi-config-standard2.sh
around lines 22 - 35, The precheck validates "${start_image}" but the VM is
launched as "rhel102-bootc", causing a mismatch; update the precheck to validate
the same image used by launch_vm by either calling exit_if_image_not_found with
the image identifier passed to launch_vm (ensure the same variable is used) or
set start_image to the image variable/name used in launch_vm so
exit_if_image_not_found and launch_vm reference the identical symbol
(references: exit_if_image_not_found, start_image, launch_vm rhel102-bootc).
| scenario_remove_vms() { | ||
| exit_if_image_not_found "${start_image}" | ||
|
|
||
| remove_vm host1 |
There was a problem hiding this comment.
Make teardown independent of image availability.
Line 39 can prevent remove_vm host1 from running. Teardown should remain best-effort even if image checks fail.
Suggested change
scenario_remove_vms() {
- exit_if_image_not_found "${start_image}"
-
remove_vm host1
}As per coding guidelines, "-Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity."
📝 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.
| scenario_remove_vms() { | |
| exit_if_image_not_found "${start_image}" | |
| remove_vm host1 | |
| scenario_remove_vms() { | |
| remove_vm host1 |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/scenarios-bootc/el10/releases/el102-lrel`@multi-config-standard2.sh
around lines 38 - 41, The teardown function scenario_remove_vms currently calls
exit_if_image_not_found "${start_image}" which can abort and prevent remove_vm
host1 from running; change scenario_remove_vms so teardown is best-effort by
removing the exit_if_image_not_found call (or moving that image existence check
to setup code) and always invoking remove_vm host1 (and any other teardown
actions) regardless of image availability; update references in the file to keep
image validation only in setup paths, not in scenario_remove_vms.
| run_tests host1 \ | ||
| --variable "PROXY_HOST:${VM_BRIDGE_IP}" \ | ||
| --variable "PROXY_PORT:9001" \ | ||
| --variable "PROMETHEUS_HOST:$(hostname)" \ | ||
| suites/storage/ \ | ||
| suites/telemetry/telemetry.robot |
There was a problem hiding this comment.
Pass PROMETHEUS_PORT to telemetry tests.
Line 23-28 passes three telemetry vars, but test/suites/telemetry/telemetry.robot also requires PROMETHEUS_PORT to be non-empty. This can cause immediate suite failure.
Suggested patch
scenario_run_tests() {
exit_if_image_not_found "${start_image}"
+ : "${PROMETHEUS_PORT:?PROMETHEUS_PORT must be set}"
run_tests host1 \
--variable "PROXY_HOST:${VM_BRIDGE_IP}" \
--variable "PROXY_PORT:9001" \
--variable "PROMETHEUS_HOST:$(hostname)" \
+ --variable "PROMETHEUS_PORT:${PROMETHEUS_PORT}" \
suites/storage/ \
suites/telemetry/telemetry.robot
}As per coding guidelines, "Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity."
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| run_tests host1 \ | |
| --variable "PROXY_HOST:${VM_BRIDGE_IP}" \ | |
| --variable "PROXY_PORT:9001" \ | |
| --variable "PROMETHEUS_HOST:$(hostname)" \ | |
| suites/storage/ \ | |
| suites/telemetry/telemetry.robot | |
| run_tests host1 \ | |
| --variable "PROXY_HOST:${VM_BRIDGE_IP}" \ | |
| --variable "PROXY_PORT:9001" \ | |
| --variable "PROMETHEUS_HOST:$(hostname)" \ | |
| --variable "PROMETHEUS_PORT:${PROMETHEUS_PORT}" \ | |
| suites/storage/ \ | |
| suites/telemetry/telemetry.robot |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/scenarios-bootc/el10/releases/el102-lrel`@storage-telemetry.sh around
lines 23 - 28, The telemetry run invocation using the run_tests host1 call
passes PROXY_HOST, PROXY_PORT and PROMETHEUS_HOST but omits PROMETHEUS_PORT
which telemetry.robot expects non-empty; update the run_tests call (the
run_tests host1 invocation) to include --variable
"PROMETHEUS_PORT:<port_or_env_value>" alongside the existing variables so
telemetry.robot receives a non-empty PROMETHEUS_PORT (use the proper port value
or substitute an env var like ${PROMETHEUS_PORT} consistent with how
PROXY_HOST/PROXY_PORT are provided).
|
@vanhalenar: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. |
No description provided.