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 'build-artifacts.sh' or 'check-patch.sh' .
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.
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 from there it could be gracefully improved - if wanted.
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.
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.
.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.
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'.
Is this task still relevant?
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 
This ticket can be closed, as we move to minikube which does not require an image build anymore.