Pierrick Bouvier <[email protected]> writes:
> On 1/27/26 10:15 AM, Alex Bennée wrote:
>> Pierrick Bouvier <[email protected]> writes:
>>
>>> On 1/27/26 1:28 AM, Alex Bennée wrote:
>>>> Richard Henderson <[email protected]> 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 [email protected] 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
