Koji build root caching

Vít Ondruch vondruch at redhat.com
Wed Jan 14 15:40:35 UTC 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dne 14.1.2015 v 16:00 Dennis Gilmore napsal(a):
> On Wed, 14 Jan 2015 14:57:59 +0100
> Miroslav Suchý <msuchy at redhat.com> wrote:
>
> > On 01/13/2015 06:01 PM, Dennis Gilmore wrote:
> >> that all being said. koji doesn't use any caching and will not use
> >> the lvm plugin. we make every buildroot from scratch using a fully
> >> clean environment to help with ensuring reproducability.
>
> > You can cache and still preserve reproducability. What I'm planning
> > for Copr is to do (every week/month) for chroot in fedora-20-x86_64
> > fedora-21_86_64 ... ; do mock --init $chroot
> >   done
> > take snapshot of that. I plan to do that on VM level.
> > And when new task come, I will just restore from that snapshot. And
> > mock will start with already populated cache. So I will have better
> > caching and yet reproducability.
>
> you really can't.  you would need to make a new cache any time one of
> the packages in the minimal buildroot changes.

Actually this is not anytime. newRepo has to be run, which is not run
more then 4 times per hour I'd say. If the new snapshot is prepared as
part of newRepo task, the mock could reuse the snapshot.


Vít

> while it may not be
> intentional you can get differences in setup and behaviour due to
> scriptlets doing different things on update and initial install. to get
> reproducability you would need to start with the same packages set and
> get the same updates. it really is not simple to do nor to track. which
> is why we purposely disable all caching.
>
> Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUto3yAAoJEAzgnueZF7h8WqoP/28+1zNKBSnYp8UfKJkBgltT
qslYPgfwKWIVDsYVAKDf1Yqi/hYXl7cQuNOwDwgROO8Y34R0zPKGOVavl9CX7j4u
+i8UGdpa9AmFe2WffTa6Z3U9rw93sMlPYtNhMKv3LeyQfgbhEIIqhVe4RL7bnht6
WfGrxWonWfipI8SL/jm60DgbT7634uoj0XZoVekETBoF67nmW5Y1U3zoLnpTJnEM
ZO0+i2hHYPfRE3nPgN6Vw983Mh8pGya2vGFyRmyL5mjgz8i5fiSD0zjxhoX6BBF9
QYqVVPCCs8IJRhvX27AOSOKc9O3aBLYg1DczSpHTWMKGGTr9TgtgU5mOQuAhA06q
8c65nI5t/owmNwjQeC2uiQHa8jaqBtpmHYDevcjnqhsSfbCcdvLRjS7b80bvNWdg
IcEv9ui6Af8+x75hTVhGUyvb7N02rQaOQx9MSVrWISG59AvRpBvE0HXM2d9lSdnN
Kzs9EHerihLO+doZNZBD6qj9AaSzY2tKXJtBQL3myhi0Oj2wmUulUAm67VZmP4XK
zZ9JGZ7DJCQOFAL2xkl/t1t4/0tDFwBZM1OFt8wQjE91CS3eCpV1iQRDVtDWZx2B
Ih6y3gRNfJMRLBdUHSVfvU32kNmvxkloT98mv5F5bhJH4cYiY8OxmEoEvmg29u/y
n7Ry0RU1Z37l7v5LvfRB
=TqRs
-----END PGP SIGNATURE-----



More information about the devel mailing list