On Fri, 7 Feb 2020 at 20:39, Cleber Rosa <cr...@redhat.com> 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 g...@gitlab.com: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
