You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Assuming we do this (perhaps under keys/$path/$etag), we have everything we would need to do the whole build offline.
As a first pass, the simplest option would be to list the entries in the corresponding cache directory and use the file with the most recent ModTime.
This makes me think we should probably start doing garbage collection on old entries (especially APKINDEX), but let's ignore that for now.
Another option would be having a symlink (perhaps latest) that gets updated to point to the most recently cached item. It would be pretty interesting to be able to go back in time to a previously cached APKINDEX and build at that point. Let's ignore this option for now and just use the latest modtime.
UX
This doesn't seem like something we want to do automatically, so let's start with an --offline flag. (I'll keep this hidden at first for testing, but if we like it, we should unhide it and start supporting it.)
If you pass the --offline flag, we'll only consult the cache for all dependencies.
If there is a cache miss, we will fail with an error rather than fetching from upstream.
We may want to introduce some commands that allow prefetching a package or index to prepare apko's cache for an offline mode: chainguard-dev/terraform-provider-apko#134
Alternatives Considered
Instead of --offline being a bool, we could do something like --offline=open or --offline=closed to indicate whether we want to fail open or closed. With --offline=open, we would just consult the cache as a source of truth before hitting upstream, which would let us trade off some consistency for availability and latency. If you're building a ton of images, this seems ideal.
Note that it is already entirely possible to point apko at a local directory (only), but it's a bit of a pain to modify your config yaml in order to make that work, and I'm particularly lazy. It might be straightforward to have offline mode just create a symlink forest that points into the cache?
The text was updated successfully, but these errors were encountered:
Background
As part of resolving the world, the first thing we do is fetch signing keys and
HEAD APKINDEX.tar.gz
to see if we have it in our cache (see #776).Our cache currently (at go-apk HEAD) looks something like this:
We don't cache signing keys at all, but we could easily do the same etag-based caching we do for APKINDEX:
E.g. something like:
Assuming we do this (perhaps under
keys/$path/$etag
), we have everything we would need to do the whole build offline.As a first pass, the simplest option would be to list the entries in the corresponding cache directory and use the file with the most recent
ModTime
.This makes me think we should probably start doing garbage collection on old entries (especially APKINDEX), but let's ignore that for now.
Another option would be having a symlink (perhaps
latest
) that gets updated to point to the most recently cached item. It would be pretty interesting to be able to go back in time to a previously cached APKINDEX and build at that point. Let's ignore this option for now and just use the latest modtime.UX
This doesn't seem like something we want to do automatically, so let's start with an
--offline
flag. (I'll keep this hidden at first for testing, but if we like it, we should unhide it and start supporting it.)If you pass the
--offline
flag, we'll only consult the cache for all dependencies.If there is a cache miss, we will fail with an error rather than fetching from upstream.
We may want to introduce some commands that allow prefetching a package or index to prepare
apko
's cache for an offline mode: chainguard-dev/terraform-provider-apko#134Alternatives Considered
Instead of
--offline
being a bool, we could do something like--offline=open
or--offline=closed
to indicate whether we want to fail open or closed. With--offline=open
, we would just consult the cache as a source of truth before hitting upstream, which would let us trade off some consistency for availability and latency. If you're building a ton of images, this seems ideal.Note that it is already entirely possible to point
apko
at a local directory (only), but it's a bit of a pain to modify your config yaml in order to make that work, and I'm particularly lazy. It might be straightforward to have offline mode just create a symlink forest that points into the cache?The text was updated successfully, but these errors were encountered: