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 reproducible builds to an OCI registry #12973
Comments
@stevehipwell been thinking about the different options at hand and comparing existing container/artifact packaging tools. Docker does not natively support adding creation timestamps via CLI options, but Podman does. For Docker, labels (associated with the There are really two options that could be applied at artifact push time:
|
@sabre1041 my preference for Helm v3 would be to support either the proposed For Helm v4 I think there are some really good use cases for driving the annotations from another location to Chart.yaml; personally I'd like to see the chart source be (more) static with common changes such as image tag/digest, CHANGELOG, etc being merged to create the package. But I guess that's another discussion; I missed the Helm 4 highway KubeCon session and can't find the recording so I don't know if this was covered. |
@stevehipwell Labels (in the traditional container build sense) are stored within the OCI Image Configuration. Helm stores the contents of the |
@sabre1041 in this case the only annotation changing is the created one, so what's required is to set that manually. I had the same issue with ORAS pushing the Artifact Hub config, but due to the |
I personally lean toward the |
@sabre1041 wouldn't the annotation pattern require significantly more code to implement? I think it's the right way to go but I'm not sure if it's a reason not to also do the pragmatic option? Adding a |
I'd like to be able to support creating Helm charts targeting an OCI registry as a reproducible build, which means being able to pass in the value for the
org.opencontainers.image.created
OCI annotation tohelm push
. This would build on the changes made in #12903 but work for cases where the package was being recreated.An example use case for this would be as follows.
CC @sabre1041
The text was updated successfully, but these errors were encountered: