<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 28, 2017 at 12:07 PM, Alfredo Moralejo Alonso <span dir="ltr"><<a href="mailto:amoralej@redhat.com" target="_blank">amoralej@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-">On Thu, Sep 28, 2017 at 4:39 PM, Wesley Hayutin <<a href="mailto:whayutin@redhat.com">whayutin@redhat.com</a>> wrote:<br>
> Greetings,<br>
><br>
> Had a brief discussion on the release delivery meeting this morning with Jon<br>
> Schlueter where as the rel-del had a requirement for the CI to constantly<br>
> execute to retest any potential changes to the delorean-deps yum repo.<br>
> This is required because it informs the import process.<br>
><br>
> Ideally we don't have to constantly tax both our hardware and people<br>
> resources because we have have an unpinned repo that can change at any<br>
> moment.<br>
><br>
> A static delorean-deps repo married to a delorean repo would be more<br>
> efficient for everyone.  How that is achieved is under discussion.<br>
><br>
<br>
</span>Having static delorean-deps repo for a RDO Trunk hash may be<br>
problematic also because centos, virtualization and ceph repos are<br>
changing repos and we may need to introduce new<br>
dependencies for the same hash.<br></blockquote><div><br></div><div>Makes sense</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">
<br>
What i'd propose is to have versioned dependencies repos so that jobs<br>
can easily report the version of deps used and replay the job with a<br>
specific dependencies snapshot if needed.<br></blockquote><div><br></div><div>Knowing if the delorean-deps have changed from one step to the next would certainly be</div><div>a step in the right direction so thank you!  This is a huge improvement over blindly </div><div>having to rerun ci ALL THE TIME.</div><div><br></div><div>It still seems like the wrong way to test a thing through a pipeline though. To properly</div><div>CI/Test software through a chain of tests over time the rpm content should be LOCKED.</div><div>I'm going to maintain this *is* a requirement.</div><div><br></div><div>If we were to host a set of rpm that included the Base OS rpms, delorean and delorean deps as</div><div>a snapshot in time via maybe pulp [1] or the equivilant then we would really be testing properly.</div><div><br></div><div>I'm not saying this needs to be done right now, however I think this is the long term goal.</div><div>I would like to discuss this goal further and see it tracked over time.</div><div><br></div><div><br></div><div>[1] <a href="http://pulpproject.org/">http://pulpproject.org/</a></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-"><br>
> This email is only to serve as an entry point for a public discussion around<br>
> that issue.<br>
><br>
> Thanks all!<br>
><br>
</span>> ______________________________<wbr>_________________<br>
> rdo-list mailing list<br>
> <a href="mailto:rdo-list@redhat.com">rdo-list@redhat.com</a><br>
> <a href="https://www.redhat.com/mailman/listinfo/rdo-list" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/rdo-list</a><br>
><br>
> To unsubscribe: <a href="mailto:rdo-list-unsubscribe@redhat.com">rdo-list-unsubscribe@redhat.<wbr>com</a><br>
</blockquote></div><br></div></div>