On Thu, Sep 28, 2017 at 12:07 PM, Alfredo Moralejo Alonso <amoralej@redhat.com> wrote:
On Thu, Sep 28, 2017 at 4:39 PM, Wesley Hayutin <whayutin@redhat.com> wrote:
> Greetings,
>
> Had a brief discussion on the release delivery meeting this morning with Jon
> Schlueter where as the rel-del had a requirement for the CI to constantly
> execute to retest any potential changes to the delorean-deps yum repo.
> This is required because it informs the import process.
>
> Ideally we don't have to constantly tax both our hardware and people
> resources because we have have an unpinned repo that can change at any
> moment.
>
> A static delorean-deps repo married to a delorean repo would be more
> efficient for everyone.  How that is achieved is under discussion.
>

Having static delorean-deps repo for a RDO Trunk hash may be
problematic also because centos, virtualization and ceph repos are
changing repos and we may need to introduce new
dependencies for the same hash.

Makes sense
 

What i'd propose is to have versioned dependencies repos so that jobs
can easily report the version of deps used and replay the job with a
specific dependencies snapshot if needed.

Knowing if the delorean-deps have changed from one step to the next would certainly be
a step in the right direction so thank you!  This is a huge improvement over blindly 
having to rerun ci ALL THE TIME.

It still seems like the wrong way to test a thing through a pipeline though. To properly
CI/Test software through a chain of tests over time the rpm content should be LOCKED.
I'm going to maintain this *is* a requirement.

If we were to host a set of rpm that included the Base OS rpms, delorean and delorean deps as
a snapshot in time via maybe pulp [1] or the equivilant then we would really be testing properly.

I'm not saying this needs to be done right now, however I think this is the long term goal.
I would like to discuss this goal further and see it tracked over time.


[1] http://pulpproject.org/


 

> This email is only to serve as an entry point for a public discussion around
> that issue.
>
> Thanks all!
>
> _______________________________________________
> rdo-list mailing list
> rdo-list@redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe@redhat.com