On Sun, Feb 5, 2017 at 11:33 AM, Martin Sivak <msi...@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 Nir > > Martin > > > On Sun, Feb 5, 2017 at 10:17 AM, Martin Sivak <msi...@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 >>> bkor...@redhat.com >>> RHCE, RHCi, RHV-DevOps Team >>> https://ifireball.wordpress.com/ >>> _______________________________________________ >>> Devel mailing list >>> de...@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel > _______________________________________________ > Devel mailing list > de...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra