I am using copr for building mom for a single reason. We have no
distgit equivalent where I would be able to mark an arbitrary git hash
as a release (using my tag and branch structure) and so copr gives me
the package release experience I want. Otherwise Jenkins would be fine
with me.

If we are getting closer to something like that then great and I will
use it when it is ready.

Martin

On Fri, Feb 10, 2017 at 9:57 AM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
>
>
> On Sun, Feb 5, 2017 at 6:25 PM, Nir Soffer <nsoffer@redhat.com> wrote:
>>
>> On Sun, Feb 5, 2017 at 11:33 AM, Martin Sivak <msivak@redhat.com> wrote:
>> >> A repo where I do not have commit rights means I can't take full
>> >> responsibility.
>> >> A repo that is not atomically synchronized with my sources means I
>> >> can't take full responsibility.
>> >
>> > Having said that, I would be perfectly fine with a single repository
>> > that tracks the release configuration, but only if it also held the
>> > git repository link and hash/branch name that is supposed to be
>> > released. It would be in some way a "distgit repo". Something like
>> > Sandro has for builds.
>> >
>> > [ovirt-4.0.x-ci]
>> > git://gerrit.ovirt.org/project.git#ovirt-4.0.x
>> > git://gerrit.ovirt.org/project2.git#v4.0.x
>> > git://github.com/Me/repo#master
>> >
>> > [ovirt-4.0.6]
>> > git://gerrit.ovirt.org/project.git#ovirt-4.0.6
>> > git://gerrit.ovirt.org/project2.git#v4.0.6
>> > http://github.com/Me/repo/releases/x.y.z.zip
>> >
>> > Any release would then be reviewed by the CI team and that would be
>> > fine for me. It would allow any branch name or versioning convention
>> > and would not pollute the sources. It would also be gerrit agnostic.
>>
>> Well said!
>>
>> May pain points with jenkins project:
>>
>> - No documentation
>> - The format is not stable, each time you edit the format is different
>> - No way to test changes, only infra guys can test changes, sometimes
>>   even infra guys cannot test changes and they simply merge them
>>   for testing
>> - The project format is full of duplication
>> - No commit right, cannot be responsible for something I cannot change
>>
>> Compare with travis:
>>
>> - Everting defined in *my* project in .travis.yml
>> - Configuration format is well documented
>>   https://docs.travis-ci.com/
>> - Configuration format is well designed, can do lot of work with very
>>   little configuration
>>   For example - this yaml define matrix of 3 builds:
>>   https://github.com/oVirt/vdsm/blob/master/.travis.yml
>> - Easy to test changes before merging (push to your fork on github)
>> - Very nice web ui, e.g.
>>   https://travis-ci.org/oVirt/vdsm/builds/198571421
>>   https://travis-ci.org/oVirt/vdsm/jobs/198571422
>>
>
> I've no strong feelings on this subject. I personally don't know travis so I
> can't compare it to anything else.
> I'm a jenkins Standard-CI user and I tend to be happy with what we have.
> That said, despite I would prefer all ovirt projects to be aligned with the
> same workflow, I'm perfectly fine with whatever CI testing / building system
> is implemented or used for each project provided that:
> - it works
> - it produces rpms which can be added to ovirt-system-test for functional
> testing
> - it produces source archives which can be published on release
> - it produces rpms which can be installed on release for all supported
> platforms and arches.
> - it doesn't require creative ways to get artifacts to be released
>
>
>
>
>>
>> Nir
>>
>> >
>> > Martin
>> >
>> >
>> > On Sun, Feb 5, 2017 at 10:17 AM, Martin Sivak <msivak@redhat.com> wrote:
>> >> Hi,
>> >>
>> >>> The fact that this is specified in the 'jenkins' repo **does not place
>> >>> this outside the maintainers` responsibility**.
>> >>
>> >> A repo where I do not have commit rights means I can't take full
>> >> responsibility.
>> >> A repo that is not atomically synchronized with my sources means I
>> >> can't take full responsibility.
>> >>
>> >>> We actually have an initiative to move this information to the project
>> >>> repos. I've started with asking on devel list about how to specify
>> >>> this as part of Standard-CI [1]. But have received little topical
>> >>> response so far.
>> >>> [1]: http://lists.ovirt.org/pipermail/devel/2017-January/029161.html
>> >>
>> >> You've got enough responses already to propose a different schema than
>> >> fixed branch names. Just give us a config file. Seriously, stop
>> >> reinventing the wheel and take a look at how others are doing it
>> >> (distgit, travis, tito, ...).
>> >>
>> >> Martin
>> >>
>> >>>
>> >>> --
>> >>> Barak Korren
>> >>> bkorren@redhat.com
>> >>> RHCE, RHCi, RHV-DevOps Team
>> >>> https://ifireball.wordpress.com/
>> >>> _______________________________________________
>> >>> Devel mailing list
>> >>> Devel@ovirt.org
>> >>> http://lists.ovirt.org/mailman/listinfo/devel
>> > _______________________________________________
>> > Devel mailing list
>> > Devel@ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/devel
>> _______________________________________________
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
>
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com