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

[Martin Sivak]

> The thing about specifying the oVirt releases in a test file is that
> this can lead to weird edge cases. Suppose for example we have the
> same text file in two branches, specifying the same oVirt releases?
> I'd like the specification to at least guarantee that an oVirt release
> can take builds from at most one branch.

Right, this can indeed be an issue. But the only way you can enforce
this without touching repository metadata is to have a separate repo
with the publisher configuration.

I believe Sandro uses something like that here:
https://gerrit.ovirt.org/gitweb?p=releng-tools.git;a=summary

You can always chose to trust us to not misconfigure the project like that :)

Martin

On Tue, Jan 10, 2017 at 2:51 PM, Barak Korren <bkorren at redhat.com> wrote:
> On 10 January 2017 at 15:32, Martin Sivak <msivak at redhat.com> wrote:
>> This is on topic. We can (and should) take inspiration in how others
>> are doing it or we will be repeating the mistakes again and again.
>>
>> Travis automation notices pushes to all branches and then uses
>> conditional checks to decide if anything needs to be done. We should
>> do the same and put all that to the automation directory. Including
>> patch testing, building, platforms and publishing.
>
> I still stand behind my assertion that Travis does not do integration.
> I'll try to clarify what I mean by that. The thing is that Travis
> always looks at a single repo. AFAIK it never tries to look across
> different repositories and compose them together to create a final
> product. You can of-course rig things together so that this sort of
> happens - you make it upload the artifacts somewhere and then trigger
> something else to do the composite test.
>
> The thing about specifying the oVirt releases in a test file is that
> this can lead to weird edge cases. Suppose for example we have the
> same text file in two branches, specifying the same oVirt releases?
> I'd like the specification to at least guarantee that an oVirt release
> can take builds from at most one branch.
>
> --
> Barak Korren
> bkorren at redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/