
On Mon, Nov 26, 2018 at 3:00 PM Marcin Sobczyk <msobczyk@redhat.com> wrote:
Hi,
I'm currently working on paralleling our stdci v2.
I've already extracted 'linters' stage, more patches (and more substages) are on the way.
This part i.e. :
if git diff-tree --no-commit-id --name-only -r HEAD | egrep --quiet 'vdsm.spec.in|Makefile.am|automation' ; then ./automation/build-artifacts.sh" ...
Please note that checks like this (about which files were changed by the
On Mon, 26 Nov 2018 at 15:10, Nir Soffer <nsoffer@redhat.com> wrote: patch) can be done via the STDCI V2 'runif' option. So you no longer need to write scripts like this.
seems to be an excellent candidate for extraction to a separate substage.
The question is - how should we proceed with tests? I can create substage for each of:
tox -e "tests,{storage,lib,network,virt}"
But the original 'check-patch' combined the coverage reports into one - we would lose that.
My long term goal is to get rid of all the ugly bash code in the makefile, and run everything via tox, but as first step I think we can split the work by running:
make tests
In the tests substage, instead of "make check" today.
Does it change anything about coverage?
Theoretically we can split also to storage/network/virt/infra jobs but I think this will consume too many resources and harm other projects sharing the slaves.
There is a possibility that we could work on something that gathers coverage data from multiple sources (tests, OST) as a completely separate jenkins job or smth, but that will be a bigger effort. What do you think about it?
Marcin
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/MR4VTN6BZFRCTP...
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted