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

[Martin Perina]

On Tue, Jan 10, 2017 at 3:17 PM, Martin Sivak <msivak at redhat.com> wrote:

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


​Yes, adding exact package version​

​into a specific file under releases worked fine so far and I don't see any
issue with that.
​
And I definitely don't want to create branches per oVirt version in smaller
projects, because we reuse the same version for multiple oVirt major
releases. So adding branch per version is a waste of time, when we can
compose repository for a version using text file under releases directory.


>
> 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/
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170111/c6fdeca3/attachment-0001.html>