public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* Run TryBot-apply_patch on the full queue?
@ 2022-09-19 13:31 Siddhesh Poyarekar
  2022-09-19 13:38 ` Siddhesh Poyarekar
  2022-09-19 16:49 ` DJ Delorie
  0 siblings, 2 replies; 8+ messages in thread
From: Siddhesh Poyarekar @ 2022-09-19 13:31 UTC (permalink / raw)
  To: dj, GNU C Library

Hi DJ,

Would you be able to run TryBot-apply_patch on the full queue (i.e. 
non-archived patches in all states that require action) on a daily basis 
and update the ones that don't apply anymore as failed?

Thanks,
Sid

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Run TryBot-apply_patch on the full queue?
  2022-09-19 13:31 Run TryBot-apply_patch on the full queue? Siddhesh Poyarekar
@ 2022-09-19 13:38 ` Siddhesh Poyarekar
  2022-09-19 16:49 ` DJ Delorie
  1 sibling, 0 replies; 8+ messages in thread
From: Siddhesh Poyarekar @ 2022-09-19 13:38 UTC (permalink / raw)
  To: dj, GNU C Library

On 2022-09-19 09:31, Siddhesh Poyarekar wrote:
> Hi DJ,
> 
> Would you be able to run TryBot-apply_patch on the full queue (i.e. 
> non-archived patches in all states that require action) on a daily basis 
> and update the ones that don't apply anymore as failed?

Oh, and as a bonus, can the trybot notify the patch submitter about it?

Thanks,
Sid

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Run TryBot-apply_patch on the full queue?
  2022-09-19 13:31 Run TryBot-apply_patch on the full queue? Siddhesh Poyarekar
  2022-09-19 13:38 ` Siddhesh Poyarekar
@ 2022-09-19 16:49 ` DJ Delorie
  2022-09-19 19:46   ` Carlos O'Donell
  1 sibling, 1 reply; 8+ messages in thread
From: DJ Delorie @ 2022-09-19 16:49 UTC (permalink / raw)
  To: Siddhesh Poyarekar; +Cc: libc-alpha


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.

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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Run TryBot-apply_patch on the full queue?
  2022-09-19 16:49 ` DJ Delorie
@ 2022-09-19 19:46   ` Carlos O'Donell
  2022-09-19 19:55     ` DJ Delorie
  0 siblings, 1 reply; 8+ messages in thread
From: Carlos O'Donell @ 2022-09-19 19:46 UTC (permalink / raw)
  To: DJ Delorie; +Cc: Siddhesh Poyarekar, libc-alpha

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.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Run TryBot-apply_patch on the full queue?
  2022-09-19 19:46   ` Carlos O'Donell
@ 2022-09-19 19:55     ` DJ Delorie
  2022-09-20 10:21       ` Carlos O'Donell
  0 siblings, 1 reply; 8+ messages in thread
From: DJ Delorie @ 2022-09-19 19:55 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: siddhesh, libc-alpha

"Carlos O'Donell" <carlos@redhat.com> writes:
> The curator/runners are a more advanced "patchwork bot" framework that
> can do very specific things.

I think it might be wise to keep the trybot API the same, though.  I
mean, if we have a "patch applies" trybot, it can be controlled by the
current curator (once per patch seen) as well as by a patchwork bot that
retries all patches once a day.

Both systems just need to inject the right json into the trybot's queue,
and that information comes mainly from patchwork anyway.

The "do once per patch" case is still common (and important) enough to
warrant a centralized curator though.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Run TryBot-apply_patch on the full queue?
  2022-09-19 19:55     ` DJ Delorie
@ 2022-09-20 10:21       ` Carlos O'Donell
  2022-09-20 14:26         ` DJ Delorie
  0 siblings, 1 reply; 8+ messages in thread
From: Carlos O'Donell @ 2022-09-20 10:21 UTC (permalink / raw)
  To: DJ Delorie; +Cc: siddhesh, libc-alpha

On Mon, Sep 19, 2022 at 03:55:51PM -0400, DJ Delorie wrote:
> "Carlos O'Donell" <carlos@redhat.com> writes:
> > The curator/runners are a more advanced "patchwork bot" framework that
> > can do very specific things.
> 
> I think it might be wise to keep the trybot API the same, though.  I
> mean, if we have a "patch applies" trybot, it can be controlled by the
> current curator (once per patch seen) as well as by a patchwork bot that
> retries all patches once a day.

That makes sense.

My only concern had been "how do you authenticate this?"

However, after having slept a full night I realized that we need signed
emails, so the curator already needs to validate signatures.

The "injection" API could take signed messages too?

> Both systems just need to inject the right json into the trybot's queue,
> and that information comes mainly from patchwork anyway.

Right.

> The "do once per patch" case is still common (and important) enough to
> warrant a centralized curator though.

Yes. We should just accept a "signed message" API?

That would reuse all the same infrastructure we have for signed emails?

c.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Run TryBot-apply_patch on the full queue?
  2022-09-20 10:21       ` Carlos O'Donell
@ 2022-09-20 14:26         ` DJ Delorie
  2022-09-20 14:39           ` Siddhesh Poyarekar
  0 siblings, 1 reply; 8+ messages in thread
From: DJ Delorie @ 2022-09-20 14:26 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: siddhesh, libc-alpha

"Carlos O'Donell" <carlos@redhat.com> writes:
> My only concern had been "how do you authenticate this?"
>
> However, after having slept a full night I realized that we need signed
> emails, so the curator already needs to validate signatures.
>
> The "injection" API could take signed messages too?

Any authentication needs to happen before the request is sent to the
trybot.  In our current scheme, it's the curator's job.  If you write
your own patchwork bot, it will be up to you to figure out what/if
you're going to authenticate.

I'll note that authentication isn't really required just to see if a
patch *applies* though.  It's a build that's a security issue.

> Yes. We should just accept a "signed message" API?

The trybot API is not public.  It trusts the runner to manage
authorizations.  Curator authenticates, runner authorizes, trybot does[*].

> That would reuse all the same infrastructure we have for signed emails?

Once we have that, sure, we can share bits of code between the curator
and other patchbots.  However, once we have that, we might not *need* to
share that between patchbots, because the curator would handle those
cases for us.

But signed emails won't solve Siddhesh's request of retrying every
pending patch every day, because they won't be signed.


[*] because, as we all know; do or do not, there is no try.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Run TryBot-apply_patch on the full queue?
  2022-09-20 14:26         ` DJ Delorie
@ 2022-09-20 14:39           ` Siddhesh Poyarekar
  0 siblings, 0 replies; 8+ messages in thread
From: Siddhesh Poyarekar @ 2022-09-20 14:39 UTC (permalink / raw)
  To: DJ Delorie, Carlos O'Donell; +Cc: libc-alpha

On 2022-09-20 10:26, DJ Delorie wrote:
> But signed emails won't solve Siddhesh's request of retrying every
> pending patch every day, because they won't be signed.

I can very simply do this from the automation I implemented to update 
committed patch states, I don't think signed emails are needed for that.

Sid

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2022-09-20 14:39 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-19 13:31 Run TryBot-apply_patch on the full queue? Siddhesh Poyarekar
2022-09-19 13:38 ` Siddhesh Poyarekar
2022-09-19 16:49 ` DJ Delorie
2022-09-19 19:46   ` Carlos O'Donell
2022-09-19 19:55     ` DJ Delorie
2022-09-20 10:21       ` Carlos O'Donell
2022-09-20 14:26         ` DJ Delorie
2022-09-20 14:39           ` Siddhesh Poyarekar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).