Use $SOURCE_DATE_EPOCH as the default for the --source-date-epoch flag
to the "build" CLI.
When a source-date-epoch is set, we'll use it when writing new history
entries, force timestamps in data written for --output to the specified
timestamp, and populate a "SOURCE_DATE_EPOCH" ARG that we treat as
always being set, and which we don't complain about being left unused.
By default, this will not affect timestamps in newly-added layers.
Add a --rewrite-timestamp flag, which "clamps" timestamps in newly-added
layers to not be later than the --source-date-epoch value if the
--source-date-epoch flag is set, but has no effect otherwise.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Make SetHas() a generic function for checking if a map holds a value of
whatever kind for a key of some comparable kind.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
With this pkg/parse does not depend on libimage.
[NO NEW TESTS NEEDED]
Based on Miloslav's work: https://github.com/containers/podman/pull/19718
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When we read TMPDIR and SSH_AUTH_SOCK from the environment, convert them
to absolute paths before using them. Call auth.GetDefaultAuthFile()
instead of reading REGISTRY_AUTH_FILE.
[NO NEW TESTS NEEDED]
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
We want to share these functions with Podman, Podman currently
has a slightly different version which is correct, so use correct
version in Buildah and vendor it into Podman.
Fixing: https://github.com/containers/podman/issues/18196
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
A non-nil but empty decryption configuration
seems to be valid enough to trigger decryption in some
configurations, per
https://github.com/containers/podman/issues/18196 .
Like in Skopeo and Podman, only decrypt when the user explicitly
instructs us to (e.g. not triggering decryption based on environment
variables).
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Stop using containerd's `platform.Normalize` instead use libimage's
`NormalizePlatform` which calls containerd's `platform.Normalize` along
with `platform.Parse` internally.
See discussion here: https://github.com/containers/buildah/pull/4286/files#r977389931
Signed-off-by: Aditya R <arajan@redhat.com>
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>
Allows end-users to export final build content or rootfs to external formats.
By default, a local container image is created from the build result. The --output (or -o) flag allows you to override this behavior, and a specify a custom exporter. For example, custom exporters allow you to export the build artifacts as files on the local filesystem instead of a Container image, which can be useful for generating local binaries, code generation etc.
The value for --output is a CSV-formatted string defining the exporter type and options. Currently, local and tar exporters are supported. The local exporter writes the resulting build files to a directory on the client side. The tar exporter is similar but writes the files as a single tarball (.tar).
```console
buildah build --output type=local,dest=dir .
buildah build --output type=tar,dest=rootfs.tar .
buildah build -o dir .
```
Reference: https://docs.docker.com/engine/reference/commandline/build/#custom-build-outputs
Signed-off-by: Aditya R <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>
Jan Kaluza
Nalin Dahyabhai
Philip Dubé
Urvashi Mohnani
Paul Holzinger
Daniel J Walsh
Miloslav Trmač
Aditya R
Sascha Grunert