[LTP] [PATCH v5 0/4] Support for Patchwork CI

[Andrea Cervesato]

On 4/15/25 11:49, Petr Vorel wrote:
> Sure, let's ignore it.
>
> FYI I did not think to add another layer. It would be git push in
> ci-patchwork-trigger.yml (more code, but OTOH ci-docker-build.yml would not have
> to be modified).
>
> Also, you decide to trigger ci-docker-build.yml via ci-patchwork-trigger.yml,
> which ignores ci-sphinx-doc.yml. Therefore patches which modify just
> documentation, e.g. even with this CI we can have changes which break
> readthedocs.org.
>
> I created a single job ci-sphinx-doc.yml because 1) it's easier to spot what got
> broken 2) I consider building the doc in all distros as a waste of time. Should
> we reconsider it? I could move building of the doc to ci-sphinx-doc.yml and
> remove ci-sphinx-doc.yml. Other option is that you trigger also ci-sphinx-doc.yml
> (nothing urgent, can be done later).
We can do it later once we have everything working for basics build tests.
>
>>> 6) Links in Patchwork contains job ID
>>> It would be nice if links in the patchwork table contain also job to the specific distro, e.g.
>>> https://github.com/acerv/ltp/actions/runs/14447250705/job/40510755305
>> It 's something I tried at the very beginning but I didn't find a solution
>> to get that "40510755305" from /job . I need to read documentation again and
>> to try a couple of solutions...it's just a really slow implementation
>> process for a simple improvement, so I bothered more about stability and
>> basic functionalities 🙂 We can add this improvement later if it's ok.
> Sure, it can wait.
>
>> There are still some things which are more important, like showing linting
>> warnings in Patchwork due to "make check" command.
> I don't consider this important until LTP is in the state when it's clean. ATM I
> would do it only for new files. For modified files I would print warning only
> when there are new warnings (compare count warning on master; comparing diff of
> warning on master vs. particular patchset will not work because line number
> changes).
>
> It should be warning only (not a failure).
>
> I guess this will be separate workflow, right? Once anybody start on it, I guess
> we should have script which takes input of changed files and generates output
> of make check-* commands.

I still don't know, we will need an implementation later on.

- Andrea