<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 10, 2017 at 2:18 PM, 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-">> While packages are separate entities and have independent life cycles,<br>
> we still need a way to compose and test oVirt as a whole. And the<br>
> responsibility to determine which version of the package goes into<br>
> which oVirt release should, in many cases lay on the shoulders of that<br>
> package maintainer.<br>
><br>
> Having distgit-like solution can be simple enough, but it sounds to me<br>
> like an overkill in many cases.<br>
><br>
> How would you suggest to solve this?<br>
<br>
</span>Well, what about another text file in the automation directory?<br>
use-for.txt with ovirt-x.y and wildcards?<br>
<span class="gmail-"><br>
> Travis never concerns itself with full system composition and<br>
> integration testing, so this is not a useful analogy at all.<br>
<br>
</span>Oh, but it does.. you can configure publishers ans webhooks in the<br>
.travis.yml file. I commonly build a project, create a docker image<br>
using the built bits and deploy to my VPS (using a branch name check).<br>
<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>What travis does not have is build chains in the sense of multiple jobs by different yaml files, but as Martin says the rest is there. What they have is different steps inside one yaml file (setup, pre_script, post_script, deployment, ...)</div><div>which can be triggered according to branches and tags.</div><div><br></div><div>In Kubevirt we also use a .travis.yaml which does testing and releasing based on tags and branches [1].</div><div><br></div><div>Note that for more finetuned controls, they also provide a lot of environment variables which you can reference (e.g. branch, tag, ...)</div><div><br></div><div>Best Regards,</div><div><br></div><div>Roman</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">
Martin<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
On Tue, Jan 10, 2017 at 1:06 PM, Barak Korren <<a href="mailto:bkorren@redhat.com">bkorren@redhat.com</a>> wrote:<br>
> On 10 January 2017 at 12:22, Martin Sivak <<a href="mailto:msivak@redhat.com">msivak@redhat.com</a>> wrote:<br>
>> Hi,<br>
>><br>
>> all of that makes sense except this:<br>
>><br>
>>> When it comes to branches, I think the way to go is to standardize<br>
>>> branch names. That standard should probably be something like<br>
>>> 'ovirt-4.0', 'ovirt-4.1', etc. Alternatively we could use something<br>
>>> like 'ovirt(-.*)?-.4.0' or (<repo_name>-4.0) to accommodate existing<br>
>>> conventions like the engine`s.<br>
>><br>
>> Do not force a branching model on me, please. We have small packages<br>
>> that either do not need any branches at all or we create the Z stream<br>
>> branch on as needed basis only. For example: mom does not need<br>
>> branches it is always compatible, ovirt-optimizer ever had only one Z<br>
>> stream patch in its history...<br>
>><br>
>> Please start treating packages as separate entities with independent<br>
>> development space. You are trying to workaround the lack of distgit by<br>
>> forcing us to play with our upstream source code repository. You<br>
>> should stop doing that as you will get into trouble once a first<br>
>> non-gerrit project is accepted to oVirt. (And we have couple of<br>
>> project where GitHub is the primary platform already)<br>
><br>
> While packages are separate entities and have independent life cycles,<br>
> we still need a way to compose and test oVirt as a whole. And the<br>
> responsibility to determine which version of the package goes into<br>
> which oVirt release should, in many cases lay on the shoulders of that<br>
> package maintainer.<br>
><br>
> Having distgit-like solution can be simple enough, but it sounds to me<br>
> like an overkill in many cases.<br>
><br>
> How would you suggest to solve this?<br>
><br>
>> The way this is done on Travis for example is much better. Pushes to<br>
>> all branches are monitored and branches with no .travis.yml (or<br>
>> automation dir in our case) are ignored.<br>
><br>
> Travis never concerns itself with full system composition and<br>
> integration testing, so this is not a useful analogy at all.<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></div></div></blockquote><div><br></div><div>[1] <a href="https://github.com/kubevirt/kubevirt/blob/master/.travis.yml">https://github.com/kubevirt/kubevirt/blob/master/.travis.yml</a> </div></div><br></div></div>