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

[Lucas Kanashiro]

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 
update the wiki page containing the exception? Do you want to do that 
instead?

Thanks again!

-- 
Lucas Kanashiro