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

[Martin Sivak]

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 at 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 at redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel