| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bash doesn't deal very well with the quoted "variant" in the
output of the oci-image-index. We can calculate the string at
the top of the function, and just use it as a whole to avoid
needing to figure out the quote escaping.
No changes in the output, except a properly quoted "variant"
when a variant is defined.
We also adjust the definition of "S", since it really wasn't
correct before, and now that we have patches, it is more
important.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
|
There are multiple different tools/techniques to generate OCI images.
Many of these techniques are part of more complex workflows, or have
many options that are needed as part of a larger system or are needed
to provide flexibility in the tooling (i.e. they construct the
container as well as build the OCI image, or they can push directly
to a registry, etc).
What we want within the build context of bitbake/oe is to not
duplicate work that is done by bitbake, the other image bbclasses
or the runtime part of the ecosystem. This means only the construction
of an image-spec v1.x image without dependencies on build, or execution
of the container within a tool. We'd also like the tool to not pull
in multiple, unused dependencies that must be built native/native-sdk,
etc, to support the simple use case.
The requirements above exclude (for now) tools such as skopeo, umoci,
buildah, img, orca-build, kaniko, scratchbuild, etc. Leading us to
a from-scratch implementation .. or enter sloci-image.
sloci-image is a simple CLI for packing a rootfs into a single layer
OCI image. It can easily be extended, or ported to other language
implementations in the future. But it brings nearly no native
dependencies and is a pure/clean implementation of the image spec
that integrates nicely in an oe/bitbake environment.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
