Hi, all of that makes sense except this:
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.
Do not force a branching model on me, please. We have small packages that either do not need any branches at all or we create the Z stream branch on as needed basis only. For example: mom does not need branches it is always compatible, ovirt-optimizer ever had only one Z stream patch in its history... Please start treating packages as separate entities with independent development space. You are trying to workaround the lack of distgit by forcing us to play with our upstream source code repository. You should stop doing that as you will get into trouble once a first non-gerrit project is accepted to oVirt. (And we have couple of project where GitHub is the primary platform already) The way this is done on Travis for example is much better. Pushes to all branches are monitored and branches with no .travis.yml (or automation dir in our case) are ignored. Martin On Tue, Jan 10, 2017 at 10:31 AM, Barak Korren <bkorren@redhat.com> wrote:
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@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel