smalltalkCI icon indicating copy to clipboard operation
smalltalkCI copied to clipboard

Cache prepared testing images for Squeak-Trunk?

Open LinqLover opened this issue 3 years ago • 2 comments

Has this ever been discussed in the past? For builds based on a Squeak-Trunk image, every single CI build takes nearly 60 seconds just for "preparing [the image] for CI" (see ./squeak/prepare.st).

Wouldn't it be an option to cache these images after created once? I could imagine two different approaches to do this:

  1. Automatically release new prepared images in this repository on a high-frequent basis (e.g., once per hour), maybe on a separate branch. Refer to their location in run_build().

    Pros:

    • No external architecture needed.

    Cons:

    • I don't know this would interfere with the current release process.
    • To what extent is the release process automated at the moment? For example, did you create the .tar.gz files in https://github.com/hpi-swa/smalltalkCI/releases/tag/v2.9.4 manually, or is this hidden somewhere in the .travis.yml file and I did not find it?
    • Not yet handled Trunk updates still would trigger manual image preparation for every single build. I don't know how many builds this actually affects, since you do not list this information on https://smalltalkci.fniephaus.com/.
  2. Outsource the preparation of trunk images to some kind of external server that uses a cache, i.e. only prepares every Trunk revision once.

    Pros:

    • Best optimized solution

    Cons:

    • Custom server needed -> configuration & maintenance effort
    • Communication to that server needs to be implemented

By the way, can you specify an arbitrary Trunk revision number for smalltalkCI at the moment, without downloading the image manually, something like smalltalk: Squeak64#19851? I believe this could be helpful, too. (For example, in https://github.com/LinqLover/Squeak-TipOfTheDay, I require #18899 or higher, so I would test both Trunk and #18899 to test backward compatibility).

PS: If a useable solution arises from this, it could possibly also be reused for other Smalltalk dialects.

LinqLover avatar Sep 24 '20 09:09 LinqLover

Hi @LinqLover,

From time to time, we bump the trunk image for smalltalkCI to reduce the time to update to the latest trunk. I don't think caching is a good idea, it often only leads to new problems.

In theory, smalltalkCI could download a trunk image (if not cached) and update it. The CI provider could cache the image and the next time, smalltalkCI will re-use that image and update from there. I'm not sure this should be done by every single user though. I'd prefer if we could automate updating the trunk image used by smalltalkCI, so that it can be done once a month for example. I think this is more or less what you are proposing with option 2. A GitHub workflow could be used for automation and would avoid the cons you mentioned.

Releasing images once per hour will very likely cause a lot of storage usage. Considering that most resources we use are free, I think it's a good idea to keep our footprint as low as possible.

By the way, can you specify an arbitrary Trunk revision number for smalltalkCI at the moment, without downloading the image manually, something like smalltalk: Squeak64#19851? I believe this could be helpful, too. (For example, in https://github.com/LinqLover/Squeak-TipOfTheDay, I require #18899 or higher, so I would test both Trunk and #18899 to test backward compatibility).

No you can't. Note that trunk images on the Squeak file server are temporary, every now and then we must free some storage to avoid flooding our disks. Only Squeak release images are considered stable, maybe we should do them more often.

What we could do is adding an option to avoid updating trunk images, so you'll always only be testing with the latest trunk image used by smalltalkCI. This would avoid slow downs over time, but my gut tells me this could also lead to new problems, so I rather keep things how they are and only increase the frequency the trunk base image is updated.

fniephaus avatar Sep 24 '20 11:09 fniephaus

Hi @fniephaus, thanks for the explanations!

Releasing images once per hour will very likely cause a lot of storage usage. Considering that most resources we use are free, I think it's a good idea to keep our footprint as low as possible.

But this problem only occurs because all old image versions are kept forever as releases for this repository, is this correct? Wouldn't it be an option to only keep the latest prepared image, maybe on an external server if you cannot remove releases from GitHub?

[Trunk revision number] No you can't. Note that trunk images on the Squeak file server are temporary, every now and then we must free some storage to avoid flooding our disks. Only Squeak release images are considered stable, maybe we should do them more often.

Couldn't we start from the latest release image and then send #doUpdate:upTo: to the McmUpdater in this line?https://github.com/hpi-swa/smalltalkCI/blob/f343d8a8b315e4a1184668e4a3ce34b92ad95332/squeak/prepare.st#L48 But of course, this would be way more expensive to cache.

LinqLover avatar Sep 25 '20 16:09 LinqLover