Re: Update on automating testing of patches and qa.guix.gnu.org

[zimoun <zimon.toutoune@gmail.com>]

Hi Chris,

On Mon, 07 Nov 2022 at 10:36, Christopher Baines <mail@cbaines.net> wrote:

> For the Git branches, there's Gitolite+cgit+some other stuff setup here
> https://git.guix-patches.cbaines.net/git/guix-patches
>
> So yes, this command should work (obviously, disabling authentication
> isn't good):
>
>   guix time-machine \
>     --url=https://git.guix-patches.cbaines.net/git/guix-patches \
>     --branch=issue-58812 --disable-authentication -- shell --symlink

That’s awesome!  It just works.  It could be a booster for reviewing
patches because:

 1. substitutes are sometimes available; which is really helpful for
 people using low-power machines,

 2. it simplifies the workflow for testing.

However, something about “guix time-machine” is not cached as expected.
Running twice in a row the same command and then

    Computing Guix derivation for 'x86_64-linux'...

is computed each time; when it should not, IIUC.   Another story. :-)


> Eventually I'd like to move this off of a machine I'm paying for, plus
> move it on to a .guix domain. Also, even though the channel instance for
> some branches might have been built by the data.qa.guix.gnu.org Guix
> Data Service, this isn't done in a way that substitutes are available,
> so that's not ideal.

What do you mean by «this isn't done in a way that substitutes are
available»?


> I'm using this list here https://qa.guix.gnu.org/patches and just
> looking at the ones at the top with the green circle by them.
>
> An API endpoint could easily be added though if that's useful.

Personally, I find easier to query and get back a list that I can
process instead of having open my webbrowser. :-)


>>>                                                 If there's any which
>>> aren't (e.g. needs some changes or more discussion), you can mark it as
>>> moreinfo to push it down the list (there's a link on the right to do
>>> this).
>>
>> Mark it as ’moreinfo’ via Debbugs?  Or something else?
>
> Yep. I'm currently trying to keep the qa-frontpage relatively stateless,
> so it's just reading the tags in debbugs.

Ok, cool!

If I remember correctly, the Data Service provides some lint
information.  We could also imagine a commit-message linter.  However,
the number of tags is rather limited.  Some time ago, we discussed
’usertag’ or else.  Well, what could be done in this area of “automatic”
tagging?


Cheers,
simon