Re: gitlab docker registries

["Alex Bennée" <alex.bennee@linaro.org>]

Pierrick Bouvier <pierrick.bouvier@linaro.org> writes:

> On 1/27/26 10:15 AM, Alex Bennée wrote:
>> Pierrick Bouvier <pierrick.bouvier@linaro.org> writes:
>> 
>>> On 1/27/26 1:28 AM, Alex Bennée wrote:
>>>> Richard Henderson <richard.henderson@linaro.org> writes:
>>>>
>>>>> On 1/27/26 10:50, Alex Bennée wrote:
>>>>>> I think it was broken by 4203ea0247f (gitlab-ci: Add build tests for
>>>>>> wasm64) because we base the tests of the existence of dockerfiles and it
>>>>>> now generates multiple targets.
>>>>>> Do we actually use the wasm32 stuff anymore? Maybe we can just
>>>>>> rename it?
>>>>>
>>>>> All of the wasm32 stuff is supposed to be gone.
>>>> I think 20260127092745.2978371-1-alex.bennee@linaro.org should fix
>>>> it,
>>>> but I need to re-read how to trigger the weekly build on my test branch
>>>> to test it.
>>>>
>>>>>
>>>>> r~
>>>>
>>>
>>> What if docker-verify was depending on building the container locally
>>> instead? It would allow to have a self-contained command, that works
>>> the same in local, or in CI, without any yaml dependencies.
>>>
>>> With current approach, it's tricky to reproduce locally as it depends
>>> on global gitlab registry, while we are just trying to see if images
>>> is buildable from scratch or not.
>> No - the point of verify was to check we where building in the
>> registry.
>>
>
> Hum, I'm not sure what "building in the registry" means. Containers
> are always built locally then (optionally) pushed to a given registry.

Yes - and this checks that the registry is up to date. We don't want to
re-build every time if it can cache. This benefits the CI and the
downstream users that pull the images.

> If you want to test something useful, it has to be a build from
> scratch (docker build --no-cache ...).
>
>> A lot of the Makefile.include stuff is legacy now (although its a useful
>> wrapper for building tests locally) because gitlab invokes the
>> containers directly. We used to do all sorts of dependency handling as
>> well but the lcitool approach is a lot cleaner even if we don't get
>> layered containers.
>>
>
> The commit message for 8bec7b9874 is:
> ```
> gitlab: add a weekly container building job
> This will hopefully catch containers that break because of upstream
> changes as well as keep the container cache fresh.
> ```
>
> IMHO, a simple weekly job doing what we want is:
> docker build --no-cache - < $dockerfile

The containers are built by the dependencies:

  needs:
    # core
    - amd64-centos9-container
    - amd64-fedora-container
    # cross
    - amd64-debian-cross-container
    - amd64-debian-user-cross-container
    - amd64-debian-legacy-cross-container
    - arm64-debian-cross-container
    - hexagon-cross-container
    - loongarch-debian-cross-container
    - mips64el-debian-cross-container
    - ppc64el-debian-cross-container
    - riscv64-debian-cross-container
    - s390x-debian-cross-container
    - tricore-debian-cross-container
    - xtensa-debian-cross-container
    - win64-fedora-cross-container
    - wasm64-emsdk-cross-container
    # containers
    - amd64-alpine-container
    - amd64-debian-container
    - amd64-ubuntu2204-container
    - amd64-opensuse-leap-container
    - python-container
    - amd64-fedora-rust-nightly-container

> I don't see what is the relation with gitlab, lcitool or Makefile.
>
> Maybe I miss some extra insights or goals that were not documented in
> original commit, but it seems like the current implementation is not
> aware of what it's supposed to do.

We occasionally see failures due to upstream distro changes. By having a
separate job we can see if it happens independent of testing staging
trees.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro