How about $subject?
So that when ovirt-system-tests_manual sees a gerrit link supplied in
CUSTOM_REPOS, it will do by itself 'ci please build' (extra points for
checking if that's already done and reusing) and use the resultant
build as if that build itself was supplied in CUSTOM_REPOS, thus
freeing the user from doing that? I find myself many times running 'ci
please build' only to later wait until it finished and then pass that
to ovirt-system-tests_manual. For projects that are very quick to
build, that's a bit tedious, but not too much. But for engine builds,
that take somewhat longer, I often forget this and come back later. It
would have been nice to be able to do this in a "single shot".
This short-cut had been asked for in 100,000 variations.
I think the best approach will be to just run OST tests per-patch (aka "patch gating").
A slightly less optimal approach would be to add a "ci please test-system" command in Gerrit.
This approach means we now have the make OST know how to build, that is very sub optimal IMO.
On Sun, Aug 20, 2017 at 5:06 PM, Barak Korren (oVirt JIRA)
I am not against this, but I was under the impression that part of the
reason for "manual" was to ease the load on slaves.
For both of above approaches, how do you suggest to pass multiple
patches/builds for different projects?
Suppose I want to run ost on pending patches for otopi+host-deploy, for example.
Perhaps. I don't mind that much the architecture, I mainly want the
If you can suggest other means for such a "single shot" command, great.
just fyi, the current manual job supports running on any projects you want, just list them one on each line. something that will be more challengin to do if you start specifying gerrit links.
The ideal solution will be to indeed enable patch gating, but it might take some time to enable, so its not feasable in the near future.
We still need to think if its possible to support something else which won't hurt our system integrity, we are working hard to make the Jenkins system
more scalable and maintainable, and we can only do that by sticking to the architecture we designed as part of "std-ci". Implemeting a hacky solution
outside of the std-ci umbrella will bring us back to weird jenkins jobs and scripts that are hard to debug and maintain going forward.
You can try perhaps writing a local script to do it for you, something like :
1. run 'build-artifacts.sh' ( or build-on-demand ) locally via mock runner for each of the projects you want to build from and save the RPMs to local repo
2. run the suite you want from ost repo, providing links to the local repos using the '-s' option. 
This is now supported by the new CLI tool written by