Re: Linking Patchwork with Sashiko?

[Mauro Carvalho Chehab <mchehab+huawei@kernel.org>]

On Wed, 3 Jun 2026 09:50:06 +1000
Matthieu Baerts <matttbe@kernel.org> wrote:

> Hi Mauro, Derek, Roman,
> 
> On 03/06/2026 06:39, Mauro Carvalho Chehab wrote:
> > On Tue, 02 Jun 2026 20:13:15 +0000
> > Roman Gushchin <roman.gushchin@linux.dev> wrote:  
> >> Derek Barbosa <debarbos@redhat.com> writes:  
> >>> On Sat, May 30, 2026 at 08:53:51PM +0200, Mauro Carvalho Chehab wrote:    
> 
> (...)
> 
> >>> - pw_tools is a workaround solution to get/set status on patchwork via bot-mail
> >>>   parsing. pw tokens also have broad permission scope.
> >>>
> >>> which that leaves us with two "methods" of integration:
> >>>
> >>> 1. The Sashiko daemon calls the pw_tools script directly to update the status.
> >>> 2. Sashiko sends a single-per-patch-email with parseable "status" to a mailing
> >>> list, where some running daemon will pickup the mail.    
> >>
> >> This feels a bit hacky.  
> > 
> > The alternative that would be acceptable, at least on media, is if 
> > one would add support on patchwork to have a separate permission just
> > for checks update.  
> 
> Indeed. It looks like there is an old feature request about that:
> 
>   https://github.com/getpatchwork/patchwork/issues/14
> 
> Linked to Mauro's email from Dec 2015 :)

Yes, this is an old request, and, as on most projects, feature 
development takes precedence over security. On that time, we wanted to 
have non-maintainer permissions to allow patch delegation. There were
more recent discussions during some Linux Media summits a couple of 
years ago, when we started implementing media-ci.

> > Granting full maintainership control to external bots sounds too risky 
> > for my taste.  
> 
> Even if I agree that's not idea, I would trust Roman's and his team not
> to mess-up with the project I maintain in Patchwork. I don't know when
> permissions will be more modular on Patchwork. That would be different
> for other services like access to the Git repo.

The problem is not trusting on people: it is trusting on a bot and
on its infra.

> My current workaround is similar to Mauro: pulling Sashiko's results,
> and publish them on Patchwork, e.g.
> 
> https://github.com/multipath-tcp/mptcp_net-next/blob/0c8d473f43cfab0ed926d694c77cb7824893af04/.github/workflows/tests.yml#L528-L596
> 
> But sometimes the pull timeouts, and that's not ideal, plus it needs to
> be updated when Sashiko has new features, etc.

That's why my model is simpler:

- handle feedback when e-mail arrives on an user's account(s) using the
  same infra that patchwork has to add patches on it. If e-mails are
  failing, patchwork won't work anyway, so there aren't any new timeout
  risks than what we had before;
- if an e-mail arrives, don't parse its content: just open a new
  context, marking as warning, so someone can later check.

---

Btw, looking on your code, you're trusting that Sashiko is properly
classifying issues.

When I was testing my new tool, I produced a broken patch by purpose,
to see if my patch would properly handle CI e-mail output:

	https://patchwork.linuxtv.org/project/linux-media/patch/9050789262f583cef777eb3a9c3e07948faf18c3.1780141190.git.mchehab+huawei@kernel.org/

If you look there, you'll see how Sashiko considered a broken
compilation patch:

	Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
	- [Low] Intentional compilation breakage via an invalid syntax token at global scope.

e.g. instead of classifying it as "High", it classified the issue
as "Low".

That's probably because, at the patch description, I mentioned that
the breakage was for testing purposes, as I didn't want devels to
waste time on it: I just wanted to pick bot answers.

In any case, the point is that one of the weakness of LLMs is that
misguided (or malicious) patch descriptions or comments can make it
do a wrong analysis and/or classification.

So, at least from my side, the best is to handle all non-success
analysis from LLM tools and from static analysis tools as warnings,
letting a human to look on it, considering the tool classification as 
just a hint.

> I guess Sashiko doesn't need pw_tools script if it has the permissions
> to publish some results on Patchwork directly. It's just one HTTP POST
> request once on the correct 'check' route, e.g.
> 
>   check_url=$(curl ${CURL_OPT} -A "${PW_AGENT}" \
>       "${PW}/api/1.3/patches/?project=${PROJECT}&msgid=${MID}" |
>        jq '.[].checks')
> 
>   curl ${CURL_OPT} \
>       -A "${PW_AGENT}" \
>       -X POST \
>       -H "Authorization: Token ${PW_TOKEN}" \
>       -F "state=${state}" \
>       -F "target_url=https://sashiko.dev/#/patchset/${MID}" \
>       -F "context=sashiko" \
>       -F "description=${desc}" \
>       "${check_url}"
> 
> See: https://patchwork.readthedocs.io/en/latest/usage/overview/#checks
> API:
> https://patchwork.readthedocs.io/en/latest/api/rest/schemas/v1.3/#post--api-1.3-patches-patch_id-checks
> Ref: https://github.com/sashiko-dev/sashiko/issues/50

Indeed it doesn't. The advantages of the script is that:
- the same script can handle different bots;
- no need to grant token maintainer's permissions to all CI
  bots;
- more control about how such token will be used, as the ones
  responsible for patchwork infra will be the ones that would be
  setting the e-mail account that will be used to update patchwork,
  and eventually storing all changes on some log.

Thanks,
Mauro