Re: [RFC PATCH] gitlab: extend timeouts for CFI builds

[Philippe Mathieu-Daudé]

On 3/22/21 3:21 PM, Alex Bennée wrote:
> These builds are running very close to the default build limit and as
> they are already pared down the only other option is to extend the
> timeout a little to give some breathing room.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  .gitlab-ci.yml | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index f746d5fbea..9ffbaa7ffb 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -502,6 +502,7 @@ build-cfi-aarch64:
>        --enable-safe-stack --enable-slirp=git
>      TARGETS: aarch64-softmmu
>      MAKE_CHECK_ARGS: check-build
> +  timeout: 70m

So this patch will potentially consume 30 more minutes per pipeline...

Having now no more free minutes, I'm a bit reluctant to the "give
us some room" approach.

Short term, this patch might help having the CI green again, so:
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>

Long term I think the problem is we expect all runner to be the
same hardware while they aren't, unlike Peter Maydell machines.

Should the tests check the runner performance and scale the
test timeout limits?

Another problem is some "container runner" (runc) are restricted
(either number of vCPU, amount of memory, capabilities).
I have the impression runners on Kubernetes are more restricted
than simple Docker runners, which perform better.