builder-common.bu: Prune untagged rhel-coreos-base and node-staging images

[ravanelli]

• Explicitly target untagged images with repository names that bypass the default dangling filter. Applied 12h retention policy for these specific images.

[gemini-code-assist]

Summary of Changes

Hello @ravanelli, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the existing image pruning mechanism by adding a targeted cleanup for specific untagged container images. The change focuses on rhel-coreos-base and node-staging images originating from the registry.ci.openshift.org/coreos registry, applying a strict 12-hour retention policy. This ensures that these particular images, which might otherwise persist, are efficiently removed, thereby optimizing storage utilization and maintaining a cleaner build environment.

Highlights

• Targeted Image Pruning: Introduced a new pruning rule specifically for untagged rhel-coreos-base and node-staging images within the registry.ci.openshift.org/coreos repository.
• Reduced Retention Policy: Applied a more aggressive 12-hour retention policy for these specific untagged images, ensuring they are removed promptly.
• Implementation Detail: The pruning is implemented via a new ExecStart command in the prune-container-resources.service unit, using podman images to filter and xargs podman rmi -f to remove the identified images.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request aims to prune specific untagged images to manage disk space. I've identified a critical issue with shell quoting in the new command that will cause it to fail, and a potential issue where the image filter may not match all the intended targets mentioned in the comments and description. My review includes a code suggestion to fix the critical quoting issue.

[gemini-code-assist]

The quoting for the awk command is incorrect. The shell invoked by bash -c will expand $2 and $1 inside the double-quoted string. Since they are unset positional parameters, they will expand to empty strings, causing awk to receive an invalid script and fail with a syntax error.

To fix this, the awk script should be enclosed in single quotes to prevent shell expansion. Since the entire bash -c command is already in single quotes, you'll need to escape the inner single quotes for awk as shown in the suggestion.

           | awk '\''$2 == "<none>" {print $1}'\'' \

[gemini-code-assist]

The comment on lines 102-103 and the PR description state that this change is for both rhel-coreos-base and node-staging images. However, the podman images filter reference=registry.ci.openshift.org/coreos/* may only match images under the coreos repository. If node-staging images are in a different repository, they will not be pruned, which could lead to disk space issues over time.

To ensure both types of images are pruned correctly, consider using a more explicit approach. For example, you could add a second ExecStart command for node-staging images, or adjust the filter to match both repository names if possible within a single command.

[HuijingHei]

LGTM, not sure if we should sync the time with above 48h.

[ravanelli]

LGTM, not sure if we should sync the time with above 48h.

We need to increase the disk as well, for now let's keep 12h, the node images are new, and the disk is getting full due the number of builds running, 12h is enough for this images, even less, they are created only during the builds, I will look if we can also clean up it, during the build as well, maybe be worth

[dustymabe]

• Explicitly target untagged images with repository names that bypass the default dangling filter. Applied 12h retention policy for these specific images.

hmm. I'm not sure I understand why the podman image prune --force isn't pruning untagged images?

What is the "default dangling filter" and why isn't it sufficient here?

[ravanelli]

• Explicitly target untagged images with repository names that bypass the default dangling filter. Applied 12h retention policy for these specific images.

hmm. I'm not sure I understand why the podman image prune --force isn't pruning untagged images?

What is the "default dangling filter" and why isn't it sufficient here?

Yeah, I was looking at that and the issue is because the dangling needs to have <none> in both the REPOSITORY and TAG columns, in this case REPOSITORY is not none.

[dustymabe]

What command do you run to view the repo and tag values for an image? podman inspect ?

[ravanelli]

What command do you run to view the repo and tag values for an image? podman inspect ?

podman images

https://docs.podman.io/en/stable/markdown/podman-images.1.html
For example in the docs we have:

List any image that is not tagged with a name (dangling):

# podman images --filter dangling=true
REPOSITORY   TAG      IMAGE ID       CREATED       SIZE
<none>       <none>   ebb91b73692b   4 weeks ago   27.2 MB