We now use the golang error wrapping format specifier `%w` instead of
the deprecated github.com/pkg/errors package.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
As builds got more complicated, the ability to only access files from one location became quite limiting. With `multi-stage` builds where you can `copy` files from other parts of the Containerfile by adding the `--from` flag and pointing it to the name of another Containerfile stage or a remote image.
The new named build context feature is an extension of this pattern. You can now define additional build contexts when running the build command, give them a name, and then access them inside a Dockerfile the same way you previously did with build stages.
Additional build contexts can be defined with a new `--build-context [name]=[value]` flag. The key component defines the name for your build context and the value can be:
```console
Local directory – e.g. --build-context project2=../path/to/project2/src
HTTP URL to a tarball – e.g. --build-context src=https://example.org/releases/src.tar
Container image – Define with a docker-image:// prefix, e.g. --build-context alpine=docker-image://alpine:3.15, ( also supports docker://, container-image:// )
```
On the Containerfile side, you can reference the build context on all commands that accept the “from” parameter. Here’s how that might look:
```Dockerfile
FROM [name]
COPY --from=[name] ...
RUN --mount=from=[name] …
```
The value of [name] is matched with the following priority order:
* Named build context defined with `--build-context [name]=..`
* Stage defined with `AS [name]` inside Dockerfile
* Remote image `[name]` in a container registry
Added Features
* Pinning images for `FROM` and `COPY`
* Specifying multiple buildcontexts from different projects
and using them with `--from` in `ADD` and `COPY` directive
* Override a Remote Dependency with a Local One.
* Using additional context from external `Tar`
Signed-off-by: Aditya R <arajan@redhat.com>
When a test needs to talk to a registry server, launch one as part of
the test rather than depending on it having been started by someone
else.
Use run_buildah where we used to use 'run buildah' without checking the
return code, and in a few cases where we did check it.
In the "from with non buildah container" test, use "podman create" with
host networking, in an attempt to avoid messing with networking in cases
where we're running on a system with a version of podman that will
create a bridge with CNI that we'll also create with netavark. We're
not sharing storage between the two invocations, so the logic that tries
to detect this problem won't detect it.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Implementation of `GetVolumes` seems to be changing with addition of new
features hence moving it from exposed parse package to internal parse
package and move needed helpers with it.
Signed-off-by: Aditya R <arajan@redhat.com>
A shared cache on host must support locking so other parallel/concurrent builds
will wait for current executing RUN statement to finish.
* Locks the cache store as soon as RUN is triggered.
* Locked target is added to cleanup list so it can be unlocked as soon
as RUN step is completed.
Signed-off-by: Aditya R <arajan@redhat.com>
Stage mounting was not functionl for systems with `selinux` enabled
following commit makes sure we enable it and removes temporary
workaround/hack which was preventing to do it.
Signed-off-by: Aditya Rajan <arajan@redhat.com>
Following commit adds buildkit like support for `from` field to `--mount=type=bind`
and `--mount=type=cache` so images and stage can be used as mount source.
Usage looks like
```dockerfile
RUN --mount=type=bind,source=.,from=<your-image>,target=/path ls /path
```
and
```dockerfile
RUN --mount=type=cache,from=<your-image>,target=/path ls /path
```
Signed-off-by: Aditya Rajan <arajan@redhat.com>
Sascha Grunert
Aditya R
Nalin Dahyabhai
Daniel J Walsh