Include docker-{buildx, compose-v2} to the Docker.io group exception

[Andreas Hasenack]

Hi,

On Fri, Sep 15, 2023 at 4:24 PM Lucas Kanashiro <kanashiro at ubuntu.com> wrote:
>
> Hi,
>
> On 14/09/2023 10:20, Andreas Hasenack wrote:
> > Hi,
> >
> > On Thu, Sep 14, 2023 at 9:54 AM Lucas Kanashiro <kanashiro at ubuntu.com> wrote:
> >> Hi,
> >>
> >> On 14/09/2023 09:33, Andreas Hasenack wrote:
> >>> Hi,
> >>>
> >>> On Thu, Sep 14, 2023 at 8:06 AM Lucas Kanashiro <kanashiro at ubuntu.com> wrote:
> >>>> Hi Andreas,
> >>>>
> >>>> On 13/09/2023 11:58, Andreas Hasenack wrote:
> >>>>> Hi Lucas,
> >>>>>
> >>>>> On Fri, Sep 1, 2023 at 6:14 PM Lucas Kanashiro <kanashiro at ubuntu.com> wrote:
> >>>>>> Hi SRU team,
> >>>>>>
> >>>>>> I'd like to ask for an update of the Docker.io group SRU exception [1]
> >>>>>> to also include the two new Docker CLI plugins that are now in the
> >>>>>> archive (Mantic):
> >>>>>>
> >>>>>> - docker-buildx
> >>>>>> - docker-compose-v2
> >>>>> Sorry for taking to long to get to this request.
> >>>> No problem.
> >>>>
> >>>>>> They are self contained (no reverse dependencies). They will also
> >>>>>> considerably improve the experience of our Docker users across all
> >>>>>> releases. Those 2 new packages are really tightened to the Docker
> >>>>>> version we have and it would be great to keep it consistent everywhere.
> >>>>>>
> >>>>>> My idea is to not allow the backport of versions .0 of those packages as
> >>>>>> we do with docker.io-app.
> >>>>>>
> >>>>>> [1] https://wiki.ubuntu.com/DockerUpdates
> >>>>> Approved on the condition that we have a few new DEP8 tests. I think
> >>> But also please see my comment about docker-compose vs
> >>> docker-compose-v2 at the end
> >>>
> >>>
> >>>>> this is importand because, per SRU exception[1] for this group of
> >>>>> packages, DEP8 tests are basically the only tests performed.
> >>>> Do you mean the current DEP-8 tests are not enough?
> >>> There is no "docker build" in the current DEP-8 tests, much less with
> >>> DOCKER_BUILDKIT=1 (I'm looking at mantic), and no test for docker
> >>> compose, even to check its presence. You are asking to include two
> >>> packages in an exception which relies on the DEP-8 tests, so yes, I
> >>> think these two new packages should be tested.
> >> There is a call to "docker build" in line 24 of d/t/basic-smoke of
> >> docker-buildx.
> > Ah, I was checking src:docker.io-app, sorry.
> >
> > Looking at the correct package now, src:docker-buildx, it uses "docker
> > buildx" indeed. Ok then, we just need a normal build (not buildx) with
> > and without the env var, like what triggered the regression report.
> > Just be wary that this env var usage might disappear in the future I
> > suppose, as buildkit becomes default. Then the test would be moot and
> > could be removed. Something to keep an eye on.
>
> +1.
>
> >
> >> The "docker compose" command is called multiple times in d/t/basic-smoke
> >> of docker-compose-v2.
> > Same thing, sorry. I was looking at src:docker.io-app. ACK on
> > docker-compose-v2, no further tests needed.
> >
> >
> >> AFAICS just the DOCKER_BUILDKIT=1 is not covered by the current tests.
> > Correct, with a normal "docker build" command.
> >
> >>> Noted on the binary package. So what will happen to the old bin:docker-compose?
> >> TBH I plan to do nothing, it is sync'ed from Debian and  it is a totally
> >> different package (even written in a different programming language).
> > Ok, that's something for an AA to sort out when the time comes.
>
> Does this mean that the addition of those two packages to the exception
> is accepted under the condition of adding DOCKER_BUILDKIT=1 to the
> docker-buildx DEP-8 test in the next upload? Should I go ahead and

Yes, DEP8 in next upload, and a manual run on this one. And a normal
"docker build" (not buildx), unless I missed that one too and it's
already being done.

> update the wiki page containing the exception? Do you want to do that
> instead?

Please do it.