Re: [PATCH 2/2] gitlab: Add cross-riscv64-system, cross-riscv64-user

[Philippe Mathieu-Daudé]

On 9/15/21 6:32 PM, Richard Henderson wrote:
> On 9/15/21 8:03 AM, Philippe Mathieu-Daudé wrote:
>> On 9/14/21 8:58 PM, Richard Henderson wrote:
>>> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
>>> ---
>>>   .gitlab-ci.d/crossbuilds.yml | 14 ++++++++++++++
>>>   1 file changed, 14 insertions(+)
>>>
>>> diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab-ci.d/crossbuilds.yml
>>> index f10168db2e..0fe4a55ac5 100644
>>> --- a/.gitlab-ci.d/crossbuilds.yml
>>> +++ b/.gitlab-ci.d/crossbuilds.yml
>>> @@ -124,6 +124,20 @@ cross-ppc64el-user:
>>>     variables:
>>>       IMAGE: debian-ppc64el-cross
>>>   +cross-riscv64-system:
>>> +  extends: .cross_system_build_job
>>> +  needs:
>>> +    job: riscv64-debian-cross-container
>>> +  variables:
>>> +    IMAGE: debian-riscv64-cross
>>> +
>>> +cross-riscv64-user:
>>> +  extends: .cross_user_build_job
>>> +  needs:
>>> +    job: riscv64-debian-cross-container
>>> +  variables:
>>> +    IMAGE: debian-riscv64-cross
>>> +
>>
>> Pending discussion on patch #1 of this series, I believe
>> this job is likely going to fail, so must use the
>> 'allow_failure: true' tag or something else (manual?).
>> Meanwhile this is sorted out:
>> NAcked-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> 
> My only question is whether it's the image creation step that should be
> allowed to fail. If the dpkg deps weren't so broken as to not install, I
> *think* we should be able to rely on the result for the cross-build.

We have multiple possibilities:

(1) Have all jobs depending on riscv64-debian-cross-container
    use 'allow_failure: true' (see commit d3a4e41da25 "gitlab-ci:
    Fix 'when:' condition in acceptance...")

(2) Use a working snapshot date, see commit b4048a7cd10 ("docker:
    Use a stable snapshot for Debian Sid")

(3) Manually push a built image to mainstream (qemu-project namespace)
    and have forks (try to build) or pull from mainstream

Hmm I had a (4) but forgot about it... Anyhow, I personally prefer (2)
over (1) because we can use it as gating. 'allow_failure' jobs are
*not* gating and we often miss their failures.