Build and check KubeVirt Demo image



a job is needed which will build the following image:

$ make clean build check

should do the job. virt-builder and guestfish are used.


Eyal Edri
February 12, 2017, 1:47 PM

any thoughts ?
Will the support for self service jobs we're thinking in adding in provide what is requesting?

Eyal Edri
February 12, 2017, 1:49 PM

can you elaborate what will the .ovirtci file contain? 'automation' dir isn't all that is needed, its mostly its scripts inside it that are supported like '' or '' .

Barak Korren
February 12, 2017, 2:15 PM

This had come down to argument about names. I think this is silly. there is nothing wrong with calling it auotmation IMO, because nothing there is necessarily oVirt-specific. You could easily make Travis run the scripts there, and perhaps you should.

includes no plan to rename automation to something else. Nor do I think it should.

Fabian Deutsch
February 13, 2017, 11:28 AM

You know - I don't disagree - if I was reading the ticket (as a 3rd person), then I'd say it's silly as well - to just discuss names.

But to be a good citizen, I'd say an ovirtci file would make sense.

the .ovirtci file could -in the easiest case - effectively have the same structure as the dir, it would just be fields in the yaml file.

and back

And from there it could be gracefully improved - if wanted.

Eyal Edri
February 13, 2017, 11:42 AM

OK, so you can also understand that changing existing framework that we've been using in the past years has a certain toll in terms of time & resources,
So I would like to know what is the main blocker or issue from your perspective from not using existing tools and for the need to develop a new standard which will require time, time that is taken from other projects, just to satisfy a single project.

Putting aside (silly) names, I think we deserve to know the reason why 'automation' dir can't be used and then we can discuss if/how we can support anything different.

Barak Korren
February 13, 2017, 2:35 PM

I wouldn't really want to shove everything into a monolithic YAML file. Personally I find the "hook script" concept much more convenient to use over time.

Maybe we can find a middle ground. How about we make things so that we fall back to the '.ovirtci' directory when 'automation' is not there?

There is also the issue of the dot (.) in ".ovirtci". I don't really think that information should be "hidden". Consider that its 'Makefile' and not '.makefile', 'Dockerfile' and not '.dockerfile'. I think '.travis' is a design error.

Fabian Deutsch
February 13, 2017, 2:58 PM

.ovirtci as a directory would also work.

To me it is a benefit to have the "namespaced" / "branded" ci files, as it gives the files a context, an dthe reader a hint of where they are getting executed.

I also do favor the fact that it's hidden, because after all, the CI is crucial, but it's not a part of the code - it is there to smoke test the code.

Barak Korren
February 14, 2017, 9:35 AM

Well, there is a big conceptual difference between '.travisci' and 'automation'. While '.travisci' was designed as just the signalling interface for the Travis system. 'automation' was designed to generalize the interface of build systems, so that a generic, isolating, dependency-resolving build system could be created. It was always a goal to also allow running the build/test process locally. In that sense 'automation' is considered as inseparable from the code as its 'Makefile'.

Daniel Belenky
May 22, 2017, 6:55 AM

Is this task still relevant?

Eyal Edri
May 22, 2017, 7:47 AM

we now support GitHub projects in standard CI and we can also build docker images, so if its still relevant,
we can help with it, there are already example of how to add new GitHub projects here [1]


Fabian Deutsch
August 23, 2017, 7:56 AM

This ticket can be closed, as we move to minikube which does not require an image build anymore.


Daniel Belenky


Fabian Deutsch