-
Notifications
You must be signed in to change notification settings - Fork 776
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[release-1.24] bump github.com/containers/storage from v1.38.3 to v1.38.5 #4084
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: nalind The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
9c664b3
to
cd7a4c1
Compare
/lgtm |
cd7a4c1
to
a7cfa7e
Compare
New changes are detected. LGTM label has been removed. |
cc1917a
to
31b50b6
Compare
Update github.com/containers/storage from v1.38.3 to v1.38.5. Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
31b50b6
to
f168e96
Compare
/retest |
Hi @rhatdan, is it possible to retry the smoke test ? |
Restarted. |
@rhatdan Thanks but it seems to be failing again... |
@cevich Any idea what is happening here? |
That's bad. I just checked, and there's no |
...sigh, we're screwd on the Plan B: Is there a podman release branch that roughly corresponds to the buildah 1.24 timeframe? Assuming so, we can simply steal the image ID from that podman branch and use it here. |
SGTM |
Poking around I found the podman v4.0 branch is using identical OS versions (packages may be a bit newer or older). More importantly, the images are still alive. Use |
What type of PR is this?
/kind other
What this PR does / why we need it:
Update github.com/containers/storage from v1.38.3 to v1.38.5, pulling in cherry-picked containers/storage#1244 and containers/storage#1274.
How to verify it
Attempt a
buildah build
using overlay with mount_program=/usr/bin/fuse-overlayfs when the storage root is itself on a virtiofs mount point.Which issue(s) this PR fixes:
None
Special notes for your reviewer:
This is a bit tricky to set up for CI, but if you're root on a Fedora 36 system, fuse-overlayfs over fuse-overlayfs seems to be close enough to be able to verify it if you're root if you're careful about the base image:
Does this PR introduce a user-facing change?