Re: [ovirt-devel] Jenkins jobs ownership

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(a)redhat.com&gt; wrote: > > > 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