[ovirt-devel] Toward self-configuring CI, or how can we stop writing YAML

Hi all, The premise of the CI standard is simple: You (the developers) place simple script in the 'automation' directory, and we (the infa team) take care of making Jenkins run it when it should. But we haven't been able to fully deliver on this premise yet. Getting a project to work with the CI standard also takes writing some YAML in the 'Jenkins' repo. Even worse, this YAML needs to be maintained over time as new project branches get created, new platforms get targeted, etc. The core reason behind having to write YAML, is that there are two technical details that we need to know in order to run the CI jobs, but are not specified in a way that allows detecting them automatically. Those details are: 1. The platforms a certain project needs to be built and tested on. 2. The branches of the project that CI needs to look at, and how do they map to an oVirt releases. We need to specify a way to specify the details above in a way that will allow the CI system to automatically detect them. Here are my ideas on how to do that: We already have a way to specify platforms in the 'automation' directory: scripts and files in the 'automation' directory can be suffixed with a platform name, this make them apply only to that platform. I suggest we make the platform suffix explicitly required (with a compatibility fall-back, see below), so that to have 'check_patch' run on Fedora 25 for x86_64, one will have to have a 'check_patch.sh.fc25.x86_64' script (or symlink) in the automation directory. It would be cumbersome to go and create symlinks in all the projects at this stage, therefore, I also suggest that we will make the architecture default to 'x86_64' when unspecified, and the OS default to 'el7'. That way, 'check_patch.sh.fc25' will be equivalent to 'check_patch.sh.fc25.x86_64', and 'check_patch.sh' will be equivalent to 'check_patch.sh.el7.x86_64'. When it comes to branches, I think the way to go is to standardize branch names. That standard should probably be something like 'ovirt-4.0', 'ovirt-4.1', etc. Alternatively we could use something like 'ovirt(-.*)?-.4.0' or (<repo_name>-4.0) to accommodate existing conventions like the engine`s. Thoughts? Ideas? ( Jira ticket tracking this work: ) ( https://ovirt-jira.atlassian.net/browse/OVIRT-1013 ) -- Barak Korren bkorren(a)redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/