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

[Martin Sivak]

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

Well, what about another text file in the automation directory?
use-for.txt with ovirt-x.y and wildcards?

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

Oh, but it does.. you can configure publishers ans webhooks in the
.travis.yml file. I commonly build a project, create a docker image
using the built bits and deploy to my VPS (using a branch name check).

Martin

On Tue, Jan 10, 2017 at 1:06 PM, Barak Korren <bkorren at redhat.com> wrote:
> 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/