On Tue, 27 Nov 2018 at 11:27, Marcin Sobczyk <[email protected]> wrote:
> Hi, > > I have another question about our approach to moving to stdci v2 - after > some talk with Martin, he suggested to make a switch from v1 to v2 just by > adding 'stdci.yaml' in master and our stable branches and turning off old > CI. Then, we would have the same old build process just with v2. > > That makes sense to me - right now I'm working with refining 'stdci.yaml' > for master (cleaning things up, splitting into substages, etc.), but the > problem is that for each patch I post *two* pipelines are being launched - > the old CI and the new one. IMHO this is abusing the infrastructure. > > By enabling v2 first and only then focusing on doing refinements we could > avoid that. > > But the real question is - do we want the new CI to be optimized > (substages etc.) for stable branches? I don't feel really comfortable with > messing with stable's build process... > Since the stdci.yaml file is committed to the branch you can decide for yourself which branches you optimize and which you don't... > Marcin > On 11/26/18 2:06 PM, Nir Soffer wrote: > > On Mon, Nov 26, 2018 at 3:00 PM Marcin Sobczyk <[email protected]> > 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" >> ... >> >> 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. > > > Will do so. > > > Does it change anything about coverage? > > We'll get separate coverage reports for py27 x el7 and {py27, py36} x fc28. > > > > 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 -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected]/message/TXAML3NLA5FW74DP4LGHZSKB5OPW5O3W/ > -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
_______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]/message/QH6KMLASTICRKJND63AUKGP5GZNR22HU/
