[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Review of debusine's autopkgtest related API



Hello Paul,

thank you for the feedback!

On Sat, 14 Oct 2023, Paul Gevers wrote:
> As on of the maintainers of the infrastructure, I have some ideas or
> recommendation to add too:
> 
> * make sure you can block tests

Do you mean specific tests within a source package or all the tests of a
source package together?

>   o ideally even per host, because in practice not all hosts will be
>     equal

That seems to overlap a bit with the "ensure you can direct certain
sources to certain hosts (or prevent certain hosts from being used)"
mentioned below but I get it.

In general, I do hope debusine to be a bit more "host"-agnostic, I
would like to be able to express scheduling requirements per
package/suite/architecture with things like:
- minimal number of CPU cores (to ensure reasonable build times for large
  packages for example)
- minimal RAM size 
- minimal size of available diskspace

>   o ideally even per backend as you intent to support multiple
>   o also *after* the job has been scheduled. As an example, recently
>     sbuild started to kill our worker service instances while we had
>     quite some backlog, which we had to fully clear to resolve the
>     issue.

You mean that you would like the allow/deny lists to also apply on tests
that are already scheduled and are in the queue, right?

That seems a bit counter-intuitive but I understand it. Wouldn't that need
be solved by having tools to cancel the problematic tests, i.e. instead of
having to flush the whole queue, we could ask "cancel all autopkgtest jobs
that will run sbuild tests" ?

> * ensure you can change the timeouts of autopkgtest

Thanks, that was missing in the initial interface that was proposed. I
added it.

>   o as the infra maintainer, e.g. you want to allow more time on slow
>     archs: armel and riscv64 at this moment

Do you hardcode bigger values or are you using --timeout-factor?

> * Maybe autopkgtest should grow an restriction to have test only run
>   when explicitly declared on the command interface, to enable writing
>   tests that don't need to run by default, but are nice to have during
>   development.

Shall I file a wishlist bug for this against autopkgtest?

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog <hertzog@debian.org>
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋    The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄⠀⠀⠀⠀   Debian Long Term Support: https://deb.li/LTS

Attachment: signature.asc
Description: PGP signature


Reply to: