Closed Antiz96 closed 5 months ago
Build succeeded. https://softwarefactory-project.io/zuul/t/local/buildset/d063343ee7374fbfb5b5f800d93a93b2
:heavy_check_mark: unit-test SUCCESS in 7m 16s :heavy_check_mark: unit-test-migration-path-for-coreos-toolbox SUCCESS in 3m 53s :heavy_check_mark: unit-test-restricted SUCCESS in 6m 03s :heavy_check_mark: system-test-fedora-rawhide SUCCESS in 31m 20s :heavy_check_mark: system-test-fedora-39 SUCCESS in 29m 05s :heavy_check_mark: system-test-fedora-38 SUCCESS in 28m 57s
@Antiz96 thanks for noticing this!
I wonder if it will be possible to add a test for this. Maybe based on:
$ ls -1 /var/cache/pacman/pkg
In the past, I managed to hack in some tests for the fedora-toolbox
images into their Containerfiles. It gives some assurance that future changes to the images or the underlying OS won't regress anything.
@debarshiray You're welcome :)
Could add a line like this for instance:
RUN [ -z "$(ls /var/cache/pacman/pkg)" ] || echo "non empty" # or exit, or whatever is needed
Although, to be honest, I'm not so worried about yes | pacman -Scc
failing to clean the cache, but you can never be too careful I guess :smile:
I can open another PR for the above test if you want to.
@debarshiray You're welcome :)
Could add a line like this for instance:
RUN [ -z "$(ls /var/cache/pacman/pkg)" ] || echo "non empty" # or exit, or whatever is needed
Sounds good to me.
Although, to be honest, I'm not so worried about
yes | pacman -Scc
failing to clean the cache, but you can never be too careful I guess 😄 I can open another PR for the above test if you want to.
Ultimately @Foxboron is the maintainer of the Arch Linux images. So, I leave it to him.
I personally tend to err on the side of caution. Someone might casually change something without checking, and then who knows? After all, you did discover this problem where the existing attempt wasn't working as expected. :)
The
--noconfirm
pacman flag automatically accepts the default answer for each questions and the default answer to removing cached packages when usingpacman -Scc
is "N" (no). That means thatpacman -Scc --noconfirm
does not actually remove cached packages.Since pacman doesn't have a way to choose to answer yes or no automatically (yet?), a simple workaround is to use
yes | pacman -Scc
instead. However, while it is recommended to setpipefail
when using pipes, it is not possible with theyes
command (see this comment for more details).Although, it should be safe to just use a piped
yes
without settingpipefail
as I don't see how it could be a cause of failure in that particular case.If using a pipe without setting
pipefail
is a concern, one can simply runrm -f /var/cache/pacman/pkg/*
instead.I can adapt this PR accordingly if needed.
I remain available if needed :slightly_smiling_face: