NO-JIRA: fix: propagate custom image build for cryptoscan in main config - #83025
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@fracappa: This pull request explicitly references no jira issue. 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. |
WalkthroughThe MicroShift configuration adds an optional Cryptoscan source image with Podman tooling and updates ChangesCryptoscan rebase execution
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 15✅ Passed checks (15 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
|
[REHEARSALNOTIFIER]
A total of 39 jobs have been affected by this change. The above listing is non-exhaustive and limited to 25 jobs. A full list of affected jobs can be found here Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@ci-operator/config/openshift/microshift/openshift-microshift-main.yaml`:
- Line 33: Update the image setup before the USER 1000 directive to initialize
the cryptoscan-required HOME and worktree paths, including $HOME/.local/bin,
$HOME/.pull-secret.json, and /go/src/github.com/openshift/microshift, and assign
ownership to UID 1000. Set HOME consistently if needed so the cryptoscan
commands can write successfully after the user switch.
- Around line 25-38: Update the existing promotion exclusion block in the
MicroShift configuration to explicitly include rebase-cryptoscan-src in
promotion.to[*].excluded_images. Leave the test-only build definition and other
promotion exclusions unchanged.
- Around line 29-30: The image setup commands for newuidmap and newgidmap must
clear their setuid-root bits before applying file capabilities. Update the
relevant installation sequence to remove setuid permissions, retain the
cap_setuid and cap_setgid capabilities, and add a concise rootless Podman smoke
test covering the final image behavior.
🪄 Autofix
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), Central YAML (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: be5e2617-0fa2-4169-b92b-6518cb7d2bb1
⛔ Files ignored due to path filters (1)
ci-operator/jobs/openshift/microshift/openshift-microshift-main-presubmits.yamlis excluded by!ci-operator/jobs/**
📒 Files selected for processing (1)
ci-operator/config/openshift/microshift/openshift-microshift-main.yaml
| - dockerfile_literal: | | ||
| FROM src | ||
| USER 0 | ||
| RUN dnf install -y podman shadow-utils jq file && dnf clean all && \ | ||
| setcap cap_setuid+ep /usr/bin/newuidmap && \ | ||
| setcap cap_setgid+ep /usr/bin/newgidmap && \ | ||
| touch /etc/subgid /etc/subuid && \ | ||
| chmod g=u /etc/subuid /etc/subgid | ||
| USER 1000 | ||
| inputs: | ||
| src: | ||
| as: | ||
| - src | ||
| to: rebase-cryptoscan-src |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf 'Tracked target file:\n'
git ls-files | rg '(^|/)openshift-microshift-main\.ya?ml$' || true
printf '\nRelevant sections of openshift-microshift-main.yaml:\n'
if [ -f ci-operator/config/openshift/microshift/openshift-microshift-main.yaml ]; then
nl -ba ci-operator/config/openshift/microshift/openshift-microshift-main.yaml | sed -n '1,180p'
fi
printf '\nSearch for rebase-cryptoscan-src and promotion exclusions:\n'
rg -n "rebase-cryptoscan-src|excluded_images|from_namespace|to:" ci-operator/config/openshift/microshift/openshift-microshift-main.yaml || true
printf '\nGenerate/relevant make update output if available:\n'
if [ -f Makefile ]; then
rg -n "^(update|generate|ci-operator|metadata)" Makefile || true
fiRepository: openshift/release
Length of output: 341
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf 'Relevant sections of openshift-microshift-main.yaml:\n'
awk '{printf "%5d %s\n", NR, $0}' ci-operator/config/openshift/microshift/openshift-microshift-main.yaml | sed -n '1,180p'
printf '\nSearch for rebase-cryptoscan-src and promotion exclusions:\n'
grep -nE "rebase-cryptoscan-src|excluded_images|from_namespace|to:" ci-operator/config/openshift/microshift/openshift-microshift-main.yaml || true
printf '\nGeneration metadata around promotion exclusions:\n'
git diff -- ci-operator/config/openshift/microshift/zz_generated_metadata || true
git diff -- ci-operator/config/openshift/microshift/openshift-microshift-main.yaml || trueRepository: openshift/release
Length of output: 6207
🌐 Web query:
ci-operator promotion excluded_images documentation
💡 Result:
In the OpenShift ci-operator configuration, the promotion.to[*].excluded_images field is used to specify a list of image names that should not be promoted to the target ImageStream [1][2]. By default, all images defined in the images block are promoted when a promotion stanza is configured; excluded_images provides a mechanism to prevent specific images from being published [3][4]. Key details regarding the use of excluded_images include: Exclusion Timing: Exclusions are applied before any additional_images are processed, meaning images listed in excluded_images will not be promoted even if they were built [2]. Wildcard Support: The * wildcard can be used to exclude all images for a specific promotion target [1][5]. This is particularly useful when you want to promote only specific, explicitly defined images via additional_images while preventing the automatic promotion of all other build images [1][6]. Purpose: It is primarily intended for scenarios where you need to build certain images for testing or intermediate steps within the CI pipeline but do not want them published to the final integration ImageStream [2]. Example configuration snippet [1][5]: promotion: to: - namespace: "ci" name: "cli-ocm" excluded_images: - "*" additional_images: latest: cli-ocm In this example, the * wildcard prevents the default promotion behavior, and only the cli-ocm image is promoted as specified in additional_images [1][5].
Citations:
- 1: https://docs.ci.openshift.org/architecture/ci-operator/
- 2: https://github.com/openshift/ci-tools/blob/master/pkg/api/types.go
- 3: https://github.com/openshift/ci-operator/blob/master/CONFIGURATION.md
- 4: https://docs.ci.openshift.org/getting-started/examples/
- 5: https://docs.ci.openshift.org/docs/architecture/ci-operator/
- 6: https://github.com/openshift/release/blob/main/ci-operator/config/openshift/hypershift/openshift-hypershift-main.yaml
Exclude rebase-cryptoscan-src from CI promotion.
rebase-cryptoscan-src is a test-only build image used by test-rebase, but it is implicitly included in promotion.to[*].excluded_images. Add it to the existing exclusion block so ci-operator does not publish it with the release output.
Proposed promotion update
- excluded_images:
- microshift-test-rpm
+ - rebase-cryptoscan-src🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@ci-operator/config/openshift/microshift/openshift-microshift-main.yaml`
around lines 25 - 38, Update the existing promotion exclusion block in the
MicroShift configuration to explicitly include rebase-cryptoscan-src in
promotion.to[*].excluded_images. Leave the test-only build definition and other
promotion exclusions unchanged.
| setcap cap_setuid+ep /usr/bin/newuidmap && \ | ||
| setcap cap_setgid+ep /usr/bin/newgidmap && \ |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== locate file =="
git ls-files | grep -F 'ci-operator/config/openshift/microshift/openshift-microshift-main.yaml' || true
echo "== relevant context =="
if [ -f ci-operator/config/openshift/microshift/openshift-microshift-main.yaml ]; then
nl -ba ci-operator/config/openshift/microshift/openshift-microshift-main.yaml | sed -n '1,220p'
fi
echo "== occurrences of setcap/newuidmap/newgidmap in config =="
rg -n "setcap|newuidmap|newgidmap|chmod u-s|chmod.*u-s|runAsNonRoot|privileged|allowPrivilegeEscalation" ci-operator/config/openshift/microshift/openshift-microshift-main.yaml || true
echo "== lockfile/tooling hints =="
git ls-files | rg '(^Makefile$|Makefile$|podman|Containerfile|Dockerfile|Dockerfile\.)|ci-operator/config' | head -200Repository: openshift/release
Length of output: 307
🌐 Web query:
Red Hat namespace setup failures uidmap gidmap setuid bits file capabilities newuidmap newgidmap
💡 Result:
Namespace setup failures involving newuidmap and newgidmap in rootless environments—such as Podman on Red Hat Enterprise Linux—typically stem from issues with file permissions, system configuration, or insufficient mapping ranges. These binaries are setuid-root to allow unprivileged users to map subordinate UIDs/GIDs into a user namespace [1][2]. Common causes and troubleshooting steps include: 1. Verification of /etc/subuid and /etc/subgid These files must contain entries for the user attempting to run the container [3][2]. If a user lacks these mappings, or if the specified ranges are invalid (e.g., overlapping with the user's own UID or excluding required IDs), namespace setup will fail [4][5][2]. 2. File Permissions and Capabilities The newuidmap and newgidmap binaries must have the correct setuid bits and file capabilities to function [6][1]. - Verify that these binaries are setuid and possess the necessary capabilities (typically cap_setuid+ep and cap_setgid+ep) [4][7]. - Security hardening policies may sometimes restrict access to configuration files like /etc/login.defs. Ensure that /etc/login.defs is world-readable (0644); restricted permissions (e.g., 0640) can prevent these tools from reading necessary configuration, resulting in exit status 1 [8]. 3. Kernel and System Constraints - User namespaces must be enabled in the kernel [3]. - If logs show warnings regarding "both setuid-root and effective capabilities," it indicates a conflict between traditional setuid bits and file capabilities, which can prevent the binaries from operating correctly [6]. - In some cases, dmesg may provide more detailed error information, such as "Permission denied" or "invalid argument," which helps distinguish between configuration errors and actual permission/capability issues [6][4][7]. To troubleshoot effectively: - Use podman unshare to test whether your user namespace mapping is functioning correctly [3]. - Check for errors in the system logs (dmesg) related to newuidmap/newgidmap [6]. - Ensure your /etc/subuid and /etc/subgid ranges are sufficient and do not overlap with the host user's own UID [4][5]. - If you suspect permission issues on configuration files, verify the readability of /etc/login.defs [8].
Citations:
- 1: https://rootlesscontaine.rs/how-it-works/userns/
- 2: https://www.redhat.com/en/blog/rootless-podman
- 3: https://access.redhat.com/articles/5946151
- 4: https://bugzilla.redhat.com/show_bug.cgi?id=1713054
- 5: https://access.redhat.com/solutions/6161832
- 6: https://access.redhat.com/solutions/7110510
- 7: Cannot run podman on fresh RHEL 8.9 installation as a non-root user podman-container-tools/podman#22309
- 8: Cannot set up namespace using /usr/bin/newuidmap - Rocky 9.2 Kernel 5.14 Podman 4.4.1 podman-container-tools/podman#19334
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== relevant context =="
awk '{printf "%6d: %s\n", NR, $0}' ci-operator/config/openshift/microshift/openshift-microshift-main.yaml | sed -n '1,220p'
echo "== occurrences =="
grep -nE "setcap|newuidmap|newgidmap|chmod .*s|chmod .*u-s|runAsNonRoot|privileged|allowPrivilegeEscalation|from .*podman|podman" ci-operator/config/openshift/microshift/openshift-microshift-main.yaml || true
echo "== podman image/config hints in repo =="
grep -RInE "setcap|cap_setuid|cap_setgid|newuidmap|newgidmap|from .*podman|podman:" ci-operator/config openshift/microshift 2>/dev/null | head -200 || true
echo "== git file type info for changed file (if available) =="
git ls-files -s ci-operator/config/openshift/microshift/openshift-microshift-main.yaml || trueRepository: openshift/release
Length of output: 33886
🌐 Web query:
Red Hat solution 7110510 setuid effective file capabilities newuidmap newgidmap
💡 Result:
Red Hat Knowledgebase Solution 7110510 addresses an issue where the podman command fails with an error related to newuidmap, specifically: "Error: cannot set up namespace using "/usr/bin/newuidmap": exit status 1" [1]. This failure is often accompanied by a kernel warning in dmesg stating that /usr/bin/newuidmap has both setuid-root permissions and effective file capabilities [1]. When a binary possesses both, the kernel may prevent it from operating correctly to maintain security boundaries [1]. The issue stems from a conflict where the shadow-utils package binaries (/usr/bin/newuidmap and /usr/bin/newgidmap) are misconfigured in certain environments, such as container images, by having both the setuid bit and file capabilities set simultaneously [1][2][3]. To resolve this issue, the standard recommendation is to ensure that the file capabilities are correctly set and that the setuid bit is removed or handled according to the system's security requirements [1][2][3]. If you encounter this on a RHEL system, you can often repair the file attributes by reinstalling the shadow-utils package or by using the rpm --setcaps command to reset the file capabilities to the values defined in the RPM package [2][3]. Reinstalling the package typically ensures the binaries receive the appropriate cap_setuid+ep and cap_setgid+ep capabilities without maintaining an improper setuid-root configuration [2].
Citations:
- 1: https://access.redhat.com/solutions/7110510
- 2: https://bugzilla.redhat.com/show_bug.cgi?id=1867598
- 3: Dockerfiles: run
rpm --setcaps shadow-utilsduring build builder#256
🌐 Web query:
openshift release setcap newuidmap newgidmap chmod u-s ci-operator
💡 Result:
The combination of commands chmod u-s, setcap, and the use of newuidmap/newgidmap is a common pattern used in OpenShift container images (such as CI/CD agents or build containers) to enable rootless container builds (e.g., using Podman or Buildah) [1][2][3]. In a standard Linux environment, newuidmap and newgidmap are setuid binaries that allow unprivileged users to map their own UIDs/GIDs in a new user namespace [4]. However, when building custom container images for use in OpenShift, these binaries may have their sticky/setuid bits set incorrectly or in a way that conflicts with container security policies (e.g., Security Context Constraints), causing permission errors during build operations [1][4]. The typical configuration pattern follows these steps: 1. chmod u-s /usr/bin/newuidmap and chmod u-s /usr/bin/newgidmap: This removes the setuid bit from these binaries [1][2]. This is often necessary because the setuid bit can be problematic or restricted within container runtimes, or it may have been set incorrectly by a base image's packaging process [1][4][5]. 2. setcap cap_setuid+eip /usr/bin/newuidmap and setcap cap_setgid+eip /usr/bin/newgidmap: After removing the setuid bit, file capabilities are applied to grant the specific necessary permissions (CAP_SETUID and CAP_SETGID) to these binaries [1][6][2]. This allows the binaries to perform their required mapping functions without requiring full root privileges for the entire process [7][3]. This configuration ensures that the container can perform rootless builds even when running with restricted permissions [1][3]. If these permissions are not correctly set, users often encounter errors such as "newuidmap: write to uid_map failed: Operation not permitted" [1][8][4]. Note: The ci-operator itself is an execution engine for OpenShift CI that manages ephemeral test clusters and build environments [9][10]. The ci-operator does not inherently mandate these specific binary configurations; rather, these configurations are applied within the Dockerfile/Containerfile of the build images (like Jenkins agents or custom runners) that ci-operator utilizes to perform containerized builds [1][2][9]. In newer versions of UBI images, some of this configuration may be handled automatically, reducing the need for manual setcap commands [3].
Citations:
- 1: https://www.redhat.com/en/blog/rootless-podman-jenkins-openshift
- 2: https://developers.redhat.com/learning/learn:securing-software-supply-chain-jenkins-tas-and-tpa-red-hat-approach/resource/learn:securing-software-supply-chain-jenkins-tas-and-tpa-red-hat-approach-prerequisites-and-step-by-step-guide
- 3: https://developers.redhat.com/articles/2024/10/01/build-container-images-openshift-using-podman-gitlab-runner
- 4: https://devopsaitoolkit.com/blog/docker-error-rootless-newuidmap-permission-denied/
- 5: Dockerfiles: run
rpm --setcaps shadow-utilsduring build builder#256 - 6: https://github.com/hippyod-labs/openshift-jenkins-non-root-image-build
- 7: rootless: /etc/sub{uid,gid} in OpenShift is tricky podman-container-tools/podman#1092
- 8: Podman Fails in OpenShift GitHub ARC Ephemeral Runner Pod Due to User Namespace Mapping (
newuidmaperror) actions/actions-runner-controller#4234 - 9: https://docs.ci.openshift.org/architecture/ci-operator/
- 10: https://github.com/openshift/ci-docs/blob/main/content/en/architecture/ci-operator.md
🌐 Web query:
site:github.com/openshift/release "chmod u-s /usr/bin/newuidmap"
💡 Result:
Running the command chmod u-s /usr/bin/newuidmap removes the setuid (set-user-ID) bit from the /usr/bin/newuidmap binary. The newuidmap utility is a system tool used in conjunction with user namespaces, a security feature in the Linux kernel that allows unprivileged users to map their own user IDs (UIDs) and group IDs (GIDs) to a range of UIDs and GIDs within a container or namespace. Because this process requires elevated privileges to modify namespace mappings, newuidmap is typically installed with the setuid bit set, allowing it to run with root privileges regardless of the user executing it. By running chmod u-s, you disable this mechanism. As a result, unprivileged users will no longer be able to use newuidmap to configure user namespaces. This will break functionality for container runtimes and tools (such as Podman or certain build systems) that rely on user namespaces to run containers or build images without requiring full root access on the host system. In environments like OpenShift or other containerized platforms, such operations are restricted to ensure that security policies are maintained. Modifying the permissions of critical system binaries like newuidmap is generally not recommended unless you specifically intend to disable user namespace support, as it will likely lead to permission denied errors when performing operations that require unprivileged namespace mapping.
Citations:
- 1: https://github.com/openshift/release/blob/main/ci-operator/step-registry/ipi/conf/aws/ipi-conf-aws-ref.yaml
- 2: add openshift/installer 'bazel build tarball' test to prow #1178
- 3: https://github.com/openshift/release/blob/dfd2beadbd400ce3ac680b2e3a430f58bcc5e63d/ci-operator/templates/master-sidecar-4.2.yaml
- 4: https://github.com/openshift/release/blob/master/Makefile
- 5: https://github.com/openshift/release/blob/main/core-services/prow/02_config/_config.yaml
🏁 Script executed:
#!/bin/bash
set -euo pipefail
tmp="$(mktemp -d)"
python3 - <<'PY' "$tmp"
import os, subprocess, tempfile
tmpdir = os.sys.argv[1]
for name in ("/usr/bin/newuidmap", "/usr/bin/newgidmap"):
src = os.path.join(tmpdir, os.path.basename(name))
os.symlink(name, src) if os.path.exists(name) else None
print("tmpdir", tmpdir)
PYRepository: openshift/release
Length of output: 182
🌐 Web query:
Linux kernel file capabilities setuid bit setcap binary setuid setuid-root effective capabilities dmesg
💡 Result:
In the Linux kernel, file capabilities and the setuid bit serve as mechanisms to grant processes elevated privileges beyond those of an unprivileged user, but they function in fundamentally different ways [1][2][3]. Traditional setuid (set-user-ID) is a binary permission bit that, when set on an executable, causes the process to run with the effective user ID of the file owner (typically root) upon execution [1][4]. This results in a complete escalation of privileges, where the process bypasses all kernel permission checks, effectively granting the "root" superuser power [1]. Because this provides total control, any vulnerability in a setuid binary can lead to full system compromise [5]. Linux capabilities break down the monolithic power of the root user into discrete, fine-grained units (such as CAP_NET_BIND_SERVICE for binding to low-numbered network ports or CAP_DAC_OVERRIDE for bypassing file read/write checks) [1][2]. File capabilities allow these specific privileges to be assigned to binaries stored in the filesystem's extended attributes (specifically, the security.capability attribute) [2][6][7]. The setcap binary is the primary tool used to manage these file-based capabilities [2][8]. When used, setcap allows an administrator to grant only the necessary permissions required for a specific task without providing full root access [2][9]. Key operational details regarding these mechanisms include: 1. Interaction: If a binary has both the setuid bit set and file capabilities assigned, the setuid behavior generally takes precedence; a setuid-root binary typically ignores file capabilities and gains all capabilities from the root's bounding set [6]. 2. Visibility: The setuid bit is visible via standard commands like ls -l (appearing as an 's' in the user execute position), whereas file capabilities are not visible in standard directory listings [5][10]. To inspect or manage them, tools like getcap or getfattr are required [6][10]. 3. Security: Utilizing capabilities is a recommended hardening practice because it adheres to the principle of least privilege, limiting the potential impact of an exploit [5][3]. 4. Kernel Logging: While there is no single specific dmesg log entry just for "using a capability," security-related denials or violations involving capabilities are often reported via the kernel's audit system or through dmesg (e.g., via SELinux or AppArmor denials if those frameworks are active). In summary, replacing setuid with file capabilities is a security-conscious approach that replaces broad, all-or-nothing root privileges with narrow, task-specific permissions [1][2][3]. {1, 3, 4, 5, 6, 7, 8, 9, 10, 11}
Citations:
- 1: https://unix.stackexchange.com/questions/55306/how-to-replace-setuid-with-file-system-capabilities
- 2: https://kernel-internals.org/security/capabilities/
- 3: https://wiki.archlinux.org/title/Using_File_Capabilities_Instead_Of_Setuid
- 4: https://docs.kernel.org/security/credentials.html
- 5: https://linux-audit.com/kernel/capabilities/linux-capabilities-hardening-linux-binaries-by-removing-setuid/
- 6: https://linuxjunkies.org/guides/linux-capabilities-explained
- 7: https://man7.org/linux/man-pages/man7/capabilities.7.html
- 8: https://www.man7.org/linux/man-pages/man8/setcap.8.html
- 9: https://www.baeldung.com/linux/set-modify-capability-permissions
- 10: https://dfir.ch/posts/linux_capabilities/
Clear setuid before applying file capabilities.
newuidmap and newgidmap come from shadow-utils with setuid-root mode. setcap alone adds file capabilities without changing that mode, and a setuid-root file plus effective file capabilities can make rootless Podman namespace setup fail. Before setcap, drop the setuid bits and add a short rootless Podman smoke test so the final image behavior is covered.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@ci-operator/config/openshift/microshift/openshift-microshift-main.yaml`
around lines 29 - 30, The image setup commands for newuidmap and newgidmap must
clear their setuid-root bits before applying file capabilities. Update the
relevant installation sequence to remove setuid permissions, retain the
cap_setuid and cap_setgid capabilities, and add a concise rootless Podman smoke
test covering the final image behavior.
| setcap cap_setgid+ep /usr/bin/newgidmap && \ | ||
| touch /etc/subgid /etc/subuid && \ | ||
| chmod g=u /etc/subuid /etc/subgid | ||
| USER 1000 |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== locate files =="
fd -a 'openshift-microshift-rebase-cryptoscan-commands.sh|openshift-microshift-main.yaml|Dockerfile|Containerfile|Dockerfile.*|Containerfile.*' . | sed 's#^\./##'
echo
echo "== target yaml excerpt =="
sed -n '1,120p' ci-operator/config/openshift/microshift/openshift-microshift-main.yaml
echo
echo "== target script excerpt =="
while IFS= read -r f; do
echo "--- $f"
sed -n '1,240p' "$f"
done < <(fd 'openshift-microshift-rebase-cryptoscan-commands.sh' .)
echo
echo "== related registry files =="
for f in $(fd 'openshift-microshift-rebase.*|cryptoscan' ci-operator/step-registry/openshift/microshift 2>/dev/null | sort); do
echo "--- $f"
sed -n '1,220p' "$f"
doneRepository: openshift/release
Length of output: 4212
🌐 Web query:
raw.githubusercontent.com openshift release master ci-operator step-registry openshift microshift rebase cryptoscan openshift-microshift-rebase-cryptoscan-commands.sh
💡 Result:
The filename openshift-microshift-rebase-cryptoscan-commands.sh does not appear to exist in the standard OpenShift release step registry [1][2][3]. The MicroShift project uses an automated rebase process [3]. The primary script used in the CI environment is openshift-microshift-rebase-commands.sh [1][2], which is located in the ci-operator/step-registry/openshift/microshift/rebase/ directory of the openshift/release repository [4][3]. This script is responsible for executing the automated rebase workflow, which synchronizes MicroShift with upstream OpenShift release versions [3]. It is possible that the filename you mentioned is a misremembered name, a custom internal script, or a very recent addition not reflected in public documentation. If you are looking for how to manage or test MicroShift rebases, the authoritative resource is the documentation found in the microshift/docs/contributor/rebase/ directory, which details the procedures for using openshift-microshift-rebase-commands.sh to perform rehearsals and tests [1][4][3].
Citations:
- 1: https://github.com/openshift/microshift/blob/main/docs/contributor/rebase/procedure.md
- 2: https://github.com/openshift/microshift/blob/main/docs/contributor/rebase.md
- 3: https://github.com/openshift/microshift/blob/main/docs/contributor/rebase/rebase.md
- 4: https://github.com/openshift/microshift/blob/main/docs/contributor/rebase/guidelines.md
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== target cryptoscan commands file raw =="
cat -n ci-operator/step-registry/openshift/microshift/rebase/cryptoscan/openshift-microshift-rebase-cryptoscan-commands.sh
echo
echo "== microshift rebase step files =="
fd -a . ci-operator/step-registry/openshift/microshift 2>/dev/null | sed 's#^\./##'
echo
echo "== workflow references =="
rg -n "openshift-microshift-rebase-cryptoscan|cryptoscan|HOME|pull-secret|\\.local/bin |/go/src/github.com/openshift/microshift" ci-operator/step-registry/openshift/microshift ci-operator/config/openshift/microshift -S
echo
echo "== related files excerpts =="
for f in $(git ls-files 'ci-operator/step-registry/openshift/microshift/*'); do
echo "--- $f"
wc -l "$f"
sed -n '1,220p' "$f"
doneRepository: openshift/release
Length of output: 50374
Ensure HOME and worktree paths are writable before switching users.
The cryptoscan commands write to $HOME/.local/bin, $HOME/.pull-secret.json, and /go/src/github.com/openshift/microshift, but the image sets USER 1000 without initializing these paths. Create and ownership these paths before the user switch, or set HOME and chown the inputs if a writable home is expected.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@ci-operator/config/openshift/microshift/openshift-microshift-main.yaml` at
line 33, Update the image setup before the USER 1000 directive to initialize the
cryptoscan-required HOME and worktree paths, including $HOME/.local/bin,
$HOME/.pull-secret.json, and /go/src/github.com/openshift/microshift, and assign
ownership to UID 1000. Set HOME consistently if needed so the cryptoscan
commands can write successfully after the user switch.
|
/pj-rehearse ack |
|
@pacevedom: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
openshift-merge-bot
Bot
added
the
rehearsals-ack
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fracappa, pacevedom The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
Bot
added
the
approved
|
@fracappa: all tests passed! 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. |
3 participants
Summary by CodeRabbit
cryptoscanimage builds.rebase-cryptoscan-srcimage with Podman, user-namespace utilities,jq, andfile.1000.test-rebasejob to support nested Podman and intranet access without network restriction.