qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] QEMU Gating CI


From: Peter Maydell
Subject: Re: [RFC] QEMU Gating CI
Date: Sat, 8 Feb 2020 13:08:07 +0000

On Fri, 7 Feb 2020 at 20:39, Cleber Rosa <address@hidden> wrote:
> On Fri, Feb 07, 2020 at 04:42:10PM +0000, Peter Maydell wrote:
> > This all sounds like the right thing and great progress. So yes,
> > I agree that the next step would be to get to a point where you
> > can give me some instructions on how to say "OK, here's my staging
> > branch" and run it through the new test process and look at the
> > results.
> >
>
> IIUC the point you're describing, we must:
>
>  * Have the rigth jobs defined in .gitlab-ci.yml (there are some
>    questions to be answered on that thread)

For the non-x86 architectures, do we define the jobs
to run on those in the same .ym file? (Generally the non-x86
machines just want to run a simple make/make check; they
don't need to check the wide variety of different configs x86 does.)

>  * Setup machines with:
>    - gitlab-runner (with tags matching OS and arch)
>    - packages needed for the actual job execution (compilers, etc)
>
> At this point, the "parallel-buildtest" command[1], would be replaced
> with something like:
>
>  - git push address@hidden:qemu-project/qemu.git staging:staging
>
> Which would automatically generate a pipeline.  Checking the results can
> be done with programmatically using the GitLab APIs[2].
>
> Once the result is validated, you would run "git push publish-upstream
> staging:master" as usual (as instructed by the script)[3].
>
> So this leaves us with the "musts" above, and also with creating a
> command line tool that uses the GitLab APIs to check on the status of
> the pipeline associated with the staging branch.

Yeah, that sounds right. To start with I'm ok with checking a web
page by hand to see what the job results are, so getting the
runners set up so we can test by doing git push is the place to start,
I think. Once we've got the actual testing going and all the machines
and configs we want to test in place, we can go back and look at
improving the UX for the person doing pullreqs so it's a bit
more automated using the GitLab APIs.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]