The support for GitHub projects in standard CI is tracked here https://ovirt-jira.atlassian.net/browse/OVIRT-970 and initial work is done now to add ovirt-web-ui as the first oVirt project to have build-artifacts triggered from GitHub.

Thanks for the feedback.

I'd like to run a job on a github repo, without the need to add he complete automation folder.

But maybe it is enough if I can come up with a freeform job when writing it in JJB YAML.

This would just mean you will be maintaining the code for your job in the 'jenkins' repo instead of in your own repo where it belongs (Try asking the Travis devs to store your '.travis' file in one of their repos...).

This would also mean that you are not going to enjoy any of the effors made over the years to improve the oVirt CI infra, in essence you are going to have to re-learn all the lessons already learned.

And come on, its not like its a massive task to create an 'automation' directory, its just a directory with simple scripts in it, and requirement files if needed. I think the learning curve to making it is far shallower then learning the whole Jenkins Job Builder syntax and how all the different system components interlock together. Being simple scripts, you get the benefit of being able to also run them locally to test without needing the whole CI infrastructure to do it.

As stated in the initial comment.

I'd like to run a job on a github repo, without the need to add he complete automation folder.

But maybe it is enough if I can come up with a freeform job when writing it in JJB YAML.

The problem with freeform jobs is that they get unmaintained fast. But we do accept patches to the 'jenkins' repo, so you can make any job you like as long as you write it in JJB YAML.

I don't think Standard-CI and Travis are fully interchangable, for example, Travis lets you ask for a Docker image to run your tests on, in Standard-CI you specify environment in terms of OS, repos and packages you want. Travis also gives you pre-baked steps for interacting with various systems, in standard CI we just let you run a script which can be limiting or liberating depending on how you look at it (We do support interacting with certain systems on your behalf, depending on the artifacts you leave behind).

Given the simplicity of Standard-CI, I think it would be possible to write a .travis.yaml file that implements it, but probably not the other way around. Then again, if you already have your CI defined in "Standard-CI" terms, you might as well let the oVirt Jenkins run it...

But before we go any further I would like to hear a more detailed description of what you are looking to do, to better understand if it fits into the standard CI framework, or if its more of an OST type of thing.

Cool - Would you grant me permissions to create jobs again, then I could experiment with freeform jobs.

I must say that I would love to write a translataion tool, translating .tarvis.yaml files to standard-ci hierarchy - maybe that can be a common ground.

We already have Jenkins hooked up to GitHub for the Lago project, and we have a Standard-CI implementation for it.