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
Now that DOI has a means of importing OCI images as-is, our non-Windows images are no longer getting much value out of being built from a Dockerfile, and we could convert that metadata directly into JSON instead.
It's probably worthwhile to consider this together with #122 (because it'll be some amount of repository churn), and might actually be a good use case for the File: support in the oci-import builder that so far hasn't had any actual load-bearing uses yet.
It's probably also worth considering doing uncompressed tarballs, since our binaries are already minimal, but it's also possible we get reasonable compression, so it's something that could be considered (we simply shouldn't rule out doing uncompressed tarballs without actually evalutating it).
The text was updated successfully, but these errors were encountered:
An alternative to consider would be doing the binary builds themselves in the Dockerfile directly (multi-stage), which would give us more interesting provenance.
Edit: something like:
FROM xxx AS build
COPY code ....
RUN compilation steps
FROM scratch AS test
COPY --from=build /hello /hello
RUN ["/hello"]
FROM scratch
COPY --from=test /hello /hello
CMD ["/hello"]
(perhaps we should track this as a separate competing issue)
Now that DOI has a means of importing OCI images as-is, our non-Windows images are no longer getting much value out of being built from a
Dockerfile
, and we could convert that metadata directly into JSON instead.See:
Builder: oci-import
support meta-scripts#20It's probably worthwhile to consider this together with #122 (because it'll be some amount of repository churn), and might actually be a good use case for the
File:
support in theoci-import
builder that so far hasn't had any actual load-bearing uses yet.It's probably also worth considering doing uncompressed tarballs, since our binaries are already minimal, but it's also possible we get reasonable compression, so it's something that could be considered (we simply shouldn't rule out doing uncompressed tarballs without actually evalutating it).
The text was updated successfully, but these errors were encountered: