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>
Add a --source-date-epoch flag, defaulting to $SOURCE_DATE_EPOCH if set,
which sets the created-on date and the timestamp for the new history
entries, but does not default to modifying the timestamps on contents in
new layers.
Add a --rewrite-timestamp flag, which "clamps" timestamps in the new
layers to not be later than the --source-date-epoch value if both
the --rewrite-timestamp and --source-date-epoch flags were set.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Allow cache mounts (RUN --mount=type=cache) to refer to other stages or
additional build contexts.
Update the build-check-cve-2024-9675 integration test to use different
directories for its main build context and the additional build context
that it uses for its final run.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Update some godocs, and update an octal value in a godoc to start with
0o instead of just 0, to match the literal on the next line.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
When using `--mount=` in RUN instruction and source is a stage make sure
that freshly built stage is used if the stage selected in source was
just rebuilt.
Closes: https://github.com/containers/buildah/issues/4522
Signed-off-by: Aditya R <arajan@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>
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>
Nalin Dahyabhai
Aditya R