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

[Barak Korren]

On 10 January 2017 at 12:22, Martin Sivak <msivak at redhat.com> wrote:
> 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)

While packages are separate entities and have independent life cycles,
we still need a way to compose and test oVirt as a whole. And the
responsibility to determine which version of the package goes into
which oVirt release should, in many cases lay on the shoulders of that
package maintainer.

Having distgit-like solution can be simple enough, but it sounds to me
like an overkill in many cases.

How would you suggest to solve this?

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

Travis never concerns itself with full system composition and
integration testing, so this is not a useful analogy at all.


-- 
Barak Korren
bkorren at redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/