Is this task still relevant?

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'.

.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.

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.

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.

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.

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.

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' .

any thoughts ?
Will the support for self service jobs we're thinking in adding in https://ovirt-jira.atlassian.net/browse/OVIRT-1013 provide what is requesting?

I'm not sure we can support it or add it, right now the whole standard CI is based on the automation dir,
starting to support something new means we need to think how/if we can support such flow and will surly delay the implementation.

I'm not sure I understand the explanation why can't you add the automation dir..., what do you mean by generic term? what do you think will happen if you'll add it?

I hesitate to add the automation dir to upstream KubeVirt, as it is such a generic term which does not fit there.

My suggestion would be to add support for an

file to generate the necessary automation/ dir.