On Fri, Feb 10, 2017 at 10:07 AM, Martin Sivak <msi...@redhat.com> wrote:
> 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. > I think you already can do that. When you want to build for a release you can create automation/mom.spec and change automaton/build-artifacts.sh to just: spectool -g automation/mom.spec rpmbuild \ -ba \ --define="_sourcedir ${PWD}" \ --define="_srcrpmdir ${PWD}" \ --define="_rpmdir ${PWD}" \ automation/mom.spec instead of ./autogen.sh ./configure --prefix=/usr make dist rpmbuild -ta *.tar.gz when jenkins will run it will build like in copr. > Martin > > On Fri, Feb 10, 2017 at 9:57 AM, Sandro Bonazzola <sbona...@redhat.com> > wrote: > > > > > > On Sun, Feb 5, 2017 at 6:25 PM, Nir Soffer <nsof...@redhat.com> wrote: > >> > >> 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 > >> > > > > 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 <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 > >> _______________________________________________ > >> Devel mailing list > >> de...@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 > -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra