Fix duplicates showing in list output #233
Conversation
39178ba to
dd9e175
Compare
dd9e175 to
9acccc1
Compare
|
Merge Failed. This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset. |
This removes an additional step when listing info about containers and images. Until now we were filtering output of podman ps to get names of containers that came from toolbox and then we got info about them. But the lack of regex support in podman caused duplicates showing when there was a "." present in the name of container. So this removes this step and simply gets all the data in the first step. This is possible thanks to the format flag in 'podman ps' that allows multiple columns to be requested. This also fixes possible duplicates of images due to a trailing space behind a variable.
This fixes false return value when running 'toolbox list -i' that was caused by the way outputs were requested.
9acccc1 to
dc468fe
Compare
| @@ -1236,23 +1196,25 @@ list_images() | |||
| ) | |||
|
|
|||
|
|
|||
| containers_get_details() | |||
| get_containers() | |||
There was a problem hiding this comment.
There's a reason why we first get the names, and then the rest of the details. :) Granted, it's a very obscure reason.
Since Podman's filters don't support using a logical or, we had to separately query the com.redhat.component and com.github.debarshiray.toolbox tagged images and merge the results into a single list.
(I wonder if we can conjure up a logical or now that Podman filters support regular expressions.)
Merging the lists using uniq(1) is tricky. We use attributes like {{.Created}} for each item, which can potentially change across two different Podman invocations if the item is new enough to be less than a minute old, and hence prevent uniq(1) from combining them into one entry.
That's why the names are first queried, merged, and then the attributes are read.
Now that we bumped our minimum Podman requirement to 1.4.0, it would've been nice if the regular expression support was also part of 1.4.0. Sadly, it isn't. It landed only in 1.5.0. Given that we still run into the occasional Podman regression (eg., containers/podman#3946) I am not comfortable hard bumping the baseline to 1.5.0. At least not yet. It would be nice to be able to keep using 1.4.0 on a best effort basis.
This might mean that we either figure out a way to detect the regular expression support at run-time and use it, or we fix this bug as part of our rewrite in Go because we'd just vendor in the necessary libpod version. I am leaning towards the latter option, myself.
This fixes #226. I just removed an additional step in the list function.