Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support container-transports in --cache-to and --cache-from #4875

Open
penn5 opened this issue Jun 22, 2023 · 10 comments · May be fixed by #4879
Open

Support container-transports in --cache-to and --cache-from #4875

penn5 opened this issue Jun 22, 2023 · 10 comments · May be fixed by #4879
Assignees

Comments

@penn5
Copy link

penn5 commented Jun 22, 2023

Description
There is no way to create a local cache without hosting a registry server on localhost and setting --cache-from/to=localhost/cache

Steps to reproduce the issue:

  1. Set --cache-from=oci:/storage when using buildah build

Describe the results you received:

Error: unable to parse value provided `[]` to --cache-from: invalid repo "oci:/storage": must contain registry and repository: invalid reference format

Describe the results you expected:
Buildah uses the provided path to cache images, allowing me to upload to CI cache coordinator.

Output of rpm -q buildah or apt list buildah:

buildah-1.30.0-1.fc38.x86_64

Output of buildah version:

Version:         1.30.0
Go Version:      go1.20.2
Image Spec:      1.0.2-dev
Runtime Spec:    1.1.0-rc.1
CNI Spec:        1.0.0
libcni Version:  v1.1.2
image Version:   5.25.0
Git Commit:      
Built:           Mon Apr 10 07:26:00 2023
OS/Arch:         linux/amd64
BuildPlatform:   linux/amd64

Output of cat /etc/*release:

NAME="Fedora Linux"
VERSION="38 (Container Image)"
ID=fedora
VERSION_ID=38
VERSION_CODENAME=""
PLATFORM_ID="platform:f38"
PRETTY_NAME="Fedora Linux 38 (Container Image)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:38"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f38/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=38
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=38
SUPPORT_END=2024-05-14
VARIANT="Container Image"
VARIANT_ID=container
Fedora release 38 (Thirty Eight)
Fedora release 38 (Thirty Eight)

Output of uname -a:

Linux c97c92126508 6.3.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jun  5 15:45:04 UTC 2023 x86_64 GNU/Linux

Output of cat /etc/containers/storage.conf:
not relevant but if you really care i'm just using the buildah:latest image, podman run buildah cat /etc/containers/stroage.conf will do it

@flouthoc
Copy link
Collaborator

This is a nice feature request, I'll take it thanks.

@flouthoc
Copy link
Collaborator

Ouch, while this is a nice feature request. I think this will break public API. I am working on a PR here, lets see if we can have consensus on this #4879

@penn5
Copy link
Author

penn5 commented Jun 26, 2023

Why would it break public API? If it does, could always add another flag --new-caching=true to switch between modes...

@flouthoc
Copy link
Collaborator

@penn5 By public api i mean the publicly exposed type CacheFrom []reference.Named -> CacheFrom []types.ImageReference :)

@penn5
Copy link
Author

penn5 commented Jun 26, 2023

Ah. I don't know Go, but my understanding is that there is not very much support for fancy types that could allow bypassing this. So either modifying the JSON deserializer to hackily deserialize as ImageReference, or making fields CacheFrom2 and CacheTo2. I would prefer the latter as the former still breaks the public API if we ever return these values, whereas with the latter we can just return a null CacheFrom and CacheTo meaning that consumers can parse the rest of the information without crashing, I hope.

@github-actions
Copy link

A friendly reminder that this issue had no activity for 30 days.

@rhatdan
Copy link
Member

rhatdan commented Jul 27, 2023

@penn5 @flouthoc anythong going on with this one?

@penn5
Copy link
Author

penn5 commented Jul 27, 2023

Not at my end, I think flouthoc was gonna try to make a patch?

@flouthoc
Copy link
Collaborator

flouthoc commented Jul 28, 2023

Yeah just waiting for @nalind and maintainers to take a look at this one #4879

@github-actions
Copy link

A friendly reminder that this issue had no activity for 30 days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants