<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 10, 2017 at 10:07 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">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></blockquote><div><br></div><div>I think you already can do that.</div><div>When you want to build for a release you can create automation/mom.spec</div><div>and change automaton/build-artifacts.sh</div><div>to just:</div><div>spectool -g automation/mom.spec</div><div><div>rpmbuild \</div><div> -ba \</div><div> --define="_sourcedir ${PWD}" \</div><div> --define="_srcrpmdir ${PWD}" \</div><div> --define="_rpmdir ${PWD}" \</div><div> automation/mom.spec</div></div><div><br></div><div>instead of</div><div><br></div><div><div>./autogen.sh</div><div>./configure --prefix=/usr</div><div>make dist</div><div>rpmbuild -ta *.tar.gz</div></div><div><br></div><div>when jenkins will run it will build like in copr.</div><div><br></div><div><br></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 9:57 AM, Sandro Bonazzola <<a href="mailto:sbonazzo@redhat.com">sbonazzo@redhat.com</a>> 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>> 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 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 the<br>
> same workflow, I'm perfectly fine with whatever CI testing / building 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 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>> wrote:<br>
>> >> Hi,<br>
>> >><br>
>> >>> The fact that this is specified in the 'jenkins' repo **does not 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 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]: <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 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 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>