The backend will figure out if we have the image or not, otherwise will
atempt to pull if not there.
Skip retrieve integration test with img as its not supported.
This changeset also drops --keep-exported-images, which is quite unused
and can be replaced with a plugin, or either by manually exporting the
resulting images.
Several changes are included:
- Expose ensureDir in helpers, and call it in the Docker client. In
other implementations that was handled by CopyFile behind the scenes,
but that's not the case here
- Create accessor in Artifact to create Artifact objects from files.
This is handy when we have to carry over downloaded package content
into caches when artifacts are already verified
- Fix various issues around the imagePush flag, so now trees are pushed
forcefully each time
- Take into consideration the real artifact name when pushing single
files in the docker image. This behavior should be changed eventually,
because single files which aren't repository packages now are in its
own docker image, but we should have just one that brings the required
metadata alltogether.
Drop image-repository on create-repo. In case of a docker repository, --output is the image reference to use.
Also restore default output build dir.
See also: #169
This is currently not a valid use case. Virtuals are empty packages and
if the `build.yaml` is completely empty, nothing could depend on them.
Let's try to not be too smart and build the package image if a source
image is supplied, and fail hardly when we depend on a virtual in build
time.
We don't need to look after the builder image as its optional. In this
way we can also reduce the compiler options, as we don't require a
--clean flag anymore. --only-target-package is sufficient to determine
what we can skip and how.
As now we build only when necessary, we need to make sure the images are
built similarly. The discrepancies between the two are less now, and
they can share the same logic.
This fixes a regresion where when no prelude is defined, the build
context isn't copied over
Collections, similarly to packages, have a `build.yaml` and
a `finalize.yaml` that are templated for each package.
They have a `collection.yaml` containing a list of
packages that are part of the tree.