[ovirt-devel] Jenkins jobs ownership

[Sandro Bonazzola]

On Sun, Feb 5, 2017 at 6:25 PM, Nir Soffer <nsoffer at redhat.com> wrote:

> On Sun, Feb 5, 2017 at 11:33 AM, Martin Sivak <msivak at 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 at 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 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
> > _______________________________________________
> > Devel mailing list
> > Devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20170210/d621e3f9/attachment-0001.html>