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

[Lucas Kanashiro]

Hi again :)

On 15/09/2023 16:39, Andreas Hasenack wrote:
> 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.

Right, I'll add the regular "docker build" as well.

Both changes in the next uploads of docker-buildx.

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

Just did it, let me know if there is any issue.

I'll be working on the backport of those packages to stable releases.

Thank you very much!

-- 
Lucas Kanashiro