<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 5, 2017 at 6:25 PM, Nir Soffer <span dir="ltr"><<a href="mailto:nsoffer@redhat.com" target="_blank">nsoffer@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">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 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>
</span>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>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>I've no strong feelings on this subject. I personally don't know travis so I can't compare it to anything else.</div><div>I'm a jenkins Standard-CI user and I tend to be happy with what we have.</div><div>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:</div><div>- it works</div><div>- it produces rpms which can be added to ovirt-system-test for functional testing</div><div>- it produces source archives which can be published on release</div><div>- it produces rpms which can be installed on release for all supported platforms and arches.</div><div>- it doesn't require creative ways to get artifacts to be released</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
Nir<br>
</font></span><div class="HOEnZb"><div class="h5"><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 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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="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>