<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 10, 2017 at 10:42 AM, Martin Sivak <span dir="ltr"><<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> I think you already can do that.<br>
> When you want to build for a release you can create automation/mom.spec<br>
> and change automaton/build-artifacts.sh<br>
<br>
</span>But that is not what I am after. I want to be able to say: Use this<br>
git hash from this repository for 4.1 and 4.0 for any upcoming release<br>
until I say otherwise (without having to use some special tag).<br>
<br>
This is not about build procedure, but about release management. The<br>
build procedure can be then part of the automation as you say, but I<br>
won't be the one executing it, Jenkins will do that for me any time<br>
you decide to do a compose.<br></blockquote><div><br></div><div>Not sure to follow.</div><div>jenkins will execute the build right after you'll merge the change.</div><div>after that, you can add the jenkins build to ovirt-<release>.conf</div><div>and it will be published for that release.</div><div>All following releases will keep that version until you add it to another ovirt-<new-release>.conf, since the files are incremental.</div><div><br></div><div>The only time this may fail is between major releases like 4.0 -> 4.1 or 4.1 -> 4.2</div><div>when beta composes are done by taking latest snapshots in ovirt-<betarelease>.conf</div><div>which I usually ask to review before merging like I did for 4.1: <a href="https://gerrit.ovirt.org/#/c/67645/">https://gerrit.ovirt.org/#/c/67645/</a></div><div><br></div><div>Maybe I'm not seeing something here.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-HOEnZb"><font color="#888888"><br>
Martin<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
On Fri, Feb 10, 2017 at 10:35 AM, Sandro Bonazzola <<a href="mailto:sbonazzo@redhat.com">sbonazzo@redhat.com</a>> wrote:<br>
><br>
><br>
> On Fri, Feb 10, 2017 at 10:07 AM, Martin Sivak <<a href="mailto:msivak@redhat.com">msivak@redhat.com</a>> wrote:<br>
>><br>
>> I am using copr for building mom for a single reason. We have no<br>
>> distgit equivalent where I would be able to mark an arbitrary git hash<br>
>> as a release (using my tag and branch structure) and so copr gives me<br>
>> the package release experience I want. Otherwise Jenkins would be fine<br>
>> with me.<br>
>><br>
>> If we are getting closer to something like that then great and I will<br>
>> use it when it is ready.<br>
><br>
><br>
> I think you already can do that.<br>
> When you want to build for a release you can create automation/mom.spec<br>
> and change automaton/build-artifacts.sh<br>
> to just:<br>
> spectool -g automation/mom.spec<br>
> rpmbuild \<br>
> -ba \<br>
> --define="_sourcedir ${PWD}" \<br>
> --define="_srcrpmdir ${PWD}" \<br>
> --define="_rpmdir ${PWD}" \<br>
> automation/mom.spec<br>
><br>
> instead of<br>
><br>
> ./autogen.sh<br>
> ./configure --prefix=/usr<br>
> make dist<br>
> rpmbuild -ta *.tar.gz<br>
><br>
> when jenkins will run it will build like in copr.<br>
><br>
><br>
>><br>
>> Martin<br>
>><br>
>> On Fri, Feb 10, 2017 at 9:57 AM, Sandro Bonazzola <<a href="mailto:sbonazzo@redhat.com">sbonazzo@redhat.com</a>><br>
>> wrote:<br>
>> ><br>
>> ><br>
>> > On Sun, Feb 5, 2017 at 6:25 PM, Nir Soffer <<a href="mailto:nsoffer@redhat.com">nsoffer@redhat.com</a>> wrote:<br>
>> >><br>
>> >> On Sun, Feb 5, 2017 at 11:33 AM, Martin Sivak <<a href="mailto:msivak@redhat.com">msivak@redhat.com</a>><br>
>> >> wrote:<br>
>> >> >> A repo where I do not have commit rights means I can't take full<br>
>> >> >> responsibility.<br>
>> >> >> A repo that is not atomically synchronized with my sources means I<br>
>> >> >> can't take full responsibility.<br>
>> >> ><br>
>> >> > Having said that, I would be perfectly fine with a single repository<br>
>> >> > that tracks the release configuration, but only if it also held the<br>
>> >> > git repository link and hash/branch name that is supposed to be<br>
>> >> > released. It would be in some way a "distgit repo". Something like<br>
>> >> > Sandro has for builds.<br>
>> >> ><br>
>> >> > [ovirt-4.0.x-ci]<br>
>> >> > git://<a href="http://gerrit.ovirt.org/project.git#ovirt-4.0.x" rel="noreferrer" target="_blank">gerrit.ovirt.org/<wbr>project.git#ovirt-4.0.x</a><br>
>> >> > git://<a href="http://gerrit.ovirt.org/project2.git#v4.0.x" rel="noreferrer" target="_blank">gerrit.ovirt.org/<wbr>project2.git#v4.0.x</a><br>
>> >> > git://<a href="http://github.com/Me/repo#master" rel="noreferrer" target="_blank">github.com/Me/repo#<wbr>master</a><br>
>> >> ><br>
>> >> > [ovirt-4.0.6]<br>
>> >> > git://<a href="http://gerrit.ovirt.org/project.git#ovirt-4.0.6" rel="noreferrer" target="_blank">gerrit.ovirt.org/<wbr>project.git#ovirt-4.0.6</a><br>
>> >> > git://<a href="http://gerrit.ovirt.org/project2.git#v4.0.6" rel="noreferrer" target="_blank">gerrit.ovirt.org/<wbr>project2.git#v4.0.6</a><br>
>> >> > <a href="http://github.com/Me/repo/releases/x.y.z.zip" rel="noreferrer" target="_blank">http://github.com/Me/repo/<wbr>releases/x.y.z.zip</a><br>
>> >> ><br>
>> >> > Any release would then be reviewed by the CI team and that would be<br>
>> >> > fine for me. It would allow any branch name or versioning convention<br>
>> >> > and would not pollute the sources. It would also be gerrit agnostic.<br>
>> >><br>
>> >> Well said!<br>
>> >><br>
>> >> May pain points with jenkins project:<br>
>> >><br>
>> >> - No documentation<br>
>> >> - The format is not stable, each time you edit the format is different<br>
>> >> - No way to test changes, only infra guys can test changes, sometimes<br>
>> >> even infra guys cannot test changes and they simply merge them<br>
>> >> for testing<br>
>> >> - The project format is full of duplication<br>
>> >> - No commit right, cannot be responsible for something I cannot change<br>
>> >><br>
>> >> Compare with travis:<br>
>> >><br>
>> >> - Everting defined in *my* project in .travis.yml<br>
>> >> - Configuration format is well documented<br>
>> >> <a href="https://docs.travis-ci.com/" rel="noreferrer" target="_blank">https://docs.travis-ci.com/</a><br>
>> >> - Configuration format is well designed, can do lot of work with very<br>
>> >> little configuration<br>
>> >> For example - this yaml define matrix of 3 builds:<br>
>> >> <a href="https://github.com/oVirt/vdsm/blob/master/.travis.yml" rel="noreferrer" target="_blank">https://github.com/oVirt/vdsm/<wbr>blob/master/.travis.yml</a><br>
>> >> - Easy to test changes before merging (push to your fork on github)<br>
>> >> - Very nice web ui, e.g.<br>
>> >> <a href="https://travis-ci.org/oVirt/vdsm/builds/198571421" rel="noreferrer" target="_blank">https://travis-ci.org/oVirt/<wbr>vdsm/builds/198571421</a><br>
>> >> <a href="https://travis-ci.org/oVirt/vdsm/jobs/198571422" rel="noreferrer" target="_blank">https://travis-ci.org/oVirt/<wbr>vdsm/jobs/198571422</a><br>
>> >><br>
>> ><br>
>> > I've no strong feelings on this subject. I personally don't know travis<br>
>> > so I<br>
>> > can't compare it to anything else.<br>
>> > I'm a jenkins Standard-CI user and I tend to be happy with what we have.<br>
>> > That said, despite I would prefer all ovirt projects to be aligned with<br>
>> > the<br>
>> > same workflow, I'm perfectly fine with whatever CI testing / building<br>
>> > system<br>
>> > is implemented or used for each project provided that:<br>
>> > - it works<br>
>> > - it produces rpms which can be added to ovirt-system-test for<br>
>> > functional<br>
>> > testing<br>
>> > - it produces source archives which can be published on release<br>
>> > - it produces rpms which can be installed on release for all supported<br>
>> > platforms and arches.<br>
>> > - it doesn't require creative ways to get artifacts to be released<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> >><br>
>> >> Nir<br>
>> >><br>
>> >> ><br>
>> >> > Martin<br>
>> >> ><br>
>> >> ><br>
>> >> > On Sun, Feb 5, 2017 at 10:17 AM, Martin Sivak <<a href="mailto:msivak@redhat.com">msivak@redhat.com</a>><br>
>> >> > wrote:<br>
>> >> >> Hi,<br>
>> >> >><br>
>> >> >>> The fact that this is specified in the 'jenkins' repo **does not<br>
>> >> >>> place<br>
>> >> >>> this outside the maintainers` responsibility**.<br>
>> >> >><br>
>> >> >> A repo where I do not have commit rights means I can't take full<br>
>> >> >> responsibility.<br>
>> >> >> A repo that is not atomically synchronized with my sources means I<br>
>> >> >> can't take full responsibility.<br>
>> >> >><br>
>> >> >>> We actually have an initiative to move this information to the<br>
>> >> >>> project<br>
>> >> >>> repos. I've started with asking on devel list about how to specify<br>
>> >> >>> this as part of Standard-CI [1]. But have received little topical<br>
>> >> >>> response so far.<br>
>> >> >>> [1]:<br>
>> >> >>> <a href="http://lists.ovirt.org/pipermail/devel/2017-January/029161.html" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>pipermail/devel/2017-January/<wbr>029161.html</a><br>
>> >> >><br>
>> >> >> You've got enough responses already to propose a different schema<br>
>> >> >> than<br>
>> >> >> fixed branch names. Just give us a config file. Seriously, stop<br>
>> >> >> reinventing the wheel and take a look at how others are doing it<br>
>> >> >> (distgit, travis, tito, ...).<br>
>> >> >><br>
>> >> >> Martin<br>
>> >> >><br>
>> >> >>><br>
>> >> >>> --<br>
>> >> >>> Barak Korren<br>
>> >> >>> <a href="mailto:bkorren@redhat.com">bkorren@redhat.com</a><br>
>> >> >>> RHCE, RHCi, RHV-DevOps Team<br>
>> >> >>> <a href="https://ifireball.wordpress.com/" rel="noreferrer" target="_blank">https://ifireball.wordpress.<wbr>com/</a><br>
>> >> >>> ______________________________<wbr>_________________<br>
>> >> >>> Devel mailing list<br>
>> >> >>> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
>> >> >>> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
>> >> > ______________________________<wbr>_________________<br>
>> >> > Devel mailing list<br>
>> >> > <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
>> >> > <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
>> >> ______________________________<wbr>_________________<br>
>> >> Devel mailing list<br>
>> >> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
>> >> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Sandro Bonazzola<br>
>> > Better technology. Faster innovation. Powered by community<br>
>> > collaboration.<br>
>> > See how it works at <a href="http://redhat.com" rel="noreferrer" target="_blank">redhat.com</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Sandro Bonazzola<br>
> Better technology. Faster innovation. Powered by community collaboration.<br>
> See how it works at <a href="http://redhat.com" rel="noreferrer" target="_blank">redhat.com</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Sandro Bonazzola<br>Better technology. Faster innovation. Powered by community collaboration.<br>See how it works at <a href="http://redhat.com" target="_blank">redhat.com</a></div></div></div></div></div></div></div></div>
</div></div>