Run TryBot-apply_patch on the full queue?

Carlos O'Donell carlos@redhat.com
Mon Sep 19 19:46:24 GMT 2022


On Mon, Sep 19, 2022 at 12:49:11PM -0400, DJ Delorie via Libc-alpha wrote:
> I'd have to write a whole new curator/runner to enqueue the jobs for the
> trybot.  So, not impossible, but not a tweak of existing software.  The
> existing system would end up doing a full build of every patch every
> day.

The curator/runners are a more advanced "patchwork bot" framework that
can do very specific things.

Currently the curator reads trusted sources for information.
Then that information is processed and runners carry out the actions.

Today the re-triggering CI due to an outage is going to require a developer
or bot to send an email to the list saying "retry CI" (signed command)
and then that will redo CI for thos failed jobs (for all curators and
runners run by all ISVs/IHVs/users/etc that listen to such a command)

We don't want to do this every day for all the patches currently in
the list that apply. This would potentially cause all listeners to
redo their patch application and builds.

However, we do want to emulate the current best practice that if a 
series doesn't rebase then we need to mark it with failed CI.

I think the best design is going to be:

- Write a custom pre-commit CI patchwork bot whose job is *only* to
  apply patches and update the patches SWF with a fail.
  - Run this daily.

- Write a patchwork bot whose job is only to mark F-fails as Failed CI.
  - Run this daily.

- Write a dashboard where the bots can report that they ran?
  - This way we can track all of our bots?

> As for notifications:
> https://github.com/getpatchwork/patchwork/issues/425

I think we'll have to eventually implment notifications via a patchwork
bot that trawls for state changes and emails developers.

Cheers,
Carlos.



More information about the Libc-alpha mailing list