Re: [ovirt-devel] Jenkins jobs ownership

On Sun, Feb 5, 2017 at 6:25 PM, Nir Soffer <nsoffer(a)redhat.com&gt; wrote: > > On Sun, Feb 5, 2017 at 11:33 AM, Martin Sivak <msivak(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com > >>> RHCE, RHCi, RHV-DevOps Team > >>> https://ifireball.wordpress.com/ > >>> _______________________________________________ > >>> Devel mailing list > >>> Devel(a)ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/devel > > _______________________________________________ > > Devel mailing list > > Devel(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > _______________________________________________ > Devel mailing list > Devel(a)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