Allows codifying build arguments into a structured file, perhaps one
named arguments.Containerargs
The build arg file also accepts comments starting #, so automated
tooling or CI/CD workflows can monitor arguments like versions to
ensure they are up-to-date.
Signed-off-by: Jack Wearden <jack@jackwearden.co.uk>
Allow containers running under buildah to use
--group-add keep-groups, so that they can inherit
access to the users groups.
Also allow users to add supplimental groups to the container.
Fixes: https://github.com/containers/buildah/issues/4476
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Buildah must support multiple sources for remote cache when using
`--cache-to` and `--cache-from` so users can distribute and collect
cache from various sources.
We also need for compat with buildkit api which in past broke `podman`
compat build API see: https://github.com/containers/podman/pull/16380
More discussion here: https://github.com/containers/podman/pull/16380
Signed-off-by: Aditya R <arajan@redhat.com>
PR #4249 added --skip-unused-stages (cool) but also added
what seems to be an unnecessary command-completion incantation.
This incantation breaks podman unit tests when vendored in
the treadmill.
[NO NEW TESTS NEEDED]
Signed-off-by: Ed Santiago <santiago@redhat.com>
In multi-stage builds buildah will skip stages which are unused (i.e
stages which don't contribute anything to target stage directly or
indirectly) however in certain cases users need to process these unused
stages hence add support for `--skip-unused-stages` which allows users
to control this behaviour.
Ref: https://github.com/GoogleContainerTools/kaniko#flag---skip-unused-stages
Closes: https://github.com/containers/buildah/issues/4243
Signed-off-by: Aditya R <arajan@redhat.com>
Allows users to configure `--retry` attempts and `--retry-delay`
duration using two additional flags for commands
* buildah build
* buildah pull
* buildah push
* buildah from
* buildah add
* buildah copy
Closes: https://github.com/containers/buildah/issues/4018
Not sure how we can test retry attempts in CI, but added a test in
tests/bud.bats which verfies we parse and added flag in other options
for sanity parsing checking.
Signed-off-by: Aditya R <arajan@redhat.com>
When `buildah manifest create` is given the `--amend` flag and a list
with the name that was specified for the to-be-created list already
exists, just reuse the list.
Make the `--insecure` flag, if we see it, conflict with `--tls-verify`,
but have the reverse of the effect that `--tls-verify` does, and teach
the `buildah manifest` `add`, `create`, and `push` subcommands about
it.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
`build` or `bud` now supports a new flag `--cache-ttl` which accepts
duration and allows end users to ignore cache images which are not under
the specified duration.
Following flag is useful for setups/platforms which heavily relies on
`--layer` and buildah caching but want recompute certain `RUN` steps
after specified duration to make sure specific `RUN` steps are always
updated. Example `RUN dnf update` or `RUN dnf install`
Closes: https://github.com/containers/buildah/issues/4160
Somewhat similar to kaniko's: https://github.com/GoogleContainerTools/kaniko#--cache-ttl-duration
Signed-off-by: Aditya R <arajan@redhat.com>
Following commit
* Initiates `cacheKey` or `layerKey` for intermediate images generated
for layers.
* Allows end users to upload cached layers with `cacheKey` to remote
sources using `--cache-to`. `--cache-to` is a optional flag to be used
with `buildah build` which publishes cached layers to remote sources.
* Allows end users to use cached layers from `remote` sources with
`--cache-from`. `--cache-from` is a optional flag to be used with
`buildah build` and it pulls cached layers from remote sources in a step
by step manner only if is a valid cache hit.
Example
* Populate cache source or use cached layers if already present
```bash
buildah build -t test --layers --cache-to registry/myrepo/cache --cache-from registry/myrepo/cache .
```
Future:
* `cacheKey` or `layerKey` model is only being used when working with
remote sources however local cache lookup can be also optimized if its
is altered to use `cacheKey` model instead of iterating through all the
images in local storage. As discussed here
References:
* Feature is quite similar to `kaniko`'s `--cache-repo`: https://github.com/GoogleContainerTools/kaniko#--cache-repo
Closes: issues#620
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>
Following PR adds support for OCI hooks attached to each of ephemeral
build contains which are created by `RUN` step invoked during `buildah
build` command.
Following PR also adds `--hooks-dir` flag to `buildah build` option
which allows end-users to specify one or more configuration directories
for OCI-hooks.
Note: Following PR migrates `pkg/hooks` from `podman` to `buildah` so
buildah could implement this feature and once merged `podman` can start
using `buildah/pkg/hooks`.
For usage see man-page and example test-case.
See: https://github.com/opencontainers/runtime-spec/blob/main/config.md#posix-platform-hooks
Closes: https://github.com/containers/buildah/issues/4068
Signed-off-by: Aditya R <arajan@redhat.com>
Support splitting build logs for multi-arch builds ( `--platform` ) by
using `--logfile` and `--logsplit` which splits generated log file in the
convention `${file}_${platform_os}_${platform_arch}`.
Closes: https://github.com/containers/buildah/issues/3960
Signed-off-by: Aditya R <arajan@redhat.com>
As per `OCI` `image-spec` setting history is optional so buildah must
support these use-cases via `--omit-history=true` some of the use-cases
are discussed below.
* There are use-cases when image-spec contributes to the image size by
adding build history to image-spec in certain use-cases this image
history is not required by the end-users but there is no way to remove
it. See: https://github.com/containers/buildah/issues/3513
* Certain build tools don't honor setting build history in image spec
however buildah does not allow processing images without build history
since setting build history is still optional as per `OCI` image-spec
( https://github.com/opencontainers/image-spec/blob/main/config.md#properties)
so buildah must support such use-cases.
Closes: https://github.com/containers/buildah/issues/4025
Closes: https://github.com/containers/buildah/issues/3513
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>
Make more of our usage information in --help output consistent with
itself, i.e., initial lower case.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Teach `buildah build` and `buildah config` about the OS version and
features fields. We don't tend to use them on Linux, but they're in the
OCI and Docker config structures, so we need to be able to preserve and
manipulate their values, much as we do for variant information.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Add a `--env` option to `buildah build` that functions similarly to the
`buildah config --env` option, to complement `buildah build`'s
`--unsetenv` option.
Document that `buildah config`'s `--env` function fetches the current
value for a variable when the name is supplied, but no `=` or value
follows it.
Signed-off-by: Nalin Dahyabhai <nalin@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>
Allow end users to remove default identity labels if they want to.
Since there are instances where images can be reproduced across version
hence users must have option to suppress default labels.
Closes: https://github.com/containers/buildah/issues/3826
Signed-off-by: Aditya R <arajan@redhat.com>
Users want to turn off addition of /etc/hosts file while building
container images, this would allow them to customize the /etc/hosts
file within the image.
Fixes: https://github.com/containers/buildah/issues/3808
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Per @edsantiago 's suggestion, make the pull commands consistent, always
accepting a value. Currently we have:
--pull
--pull=true
--pull=false
--pull-never
--pull-always
With this changes, we will only have pull with a variety of options,
ala:
--pull
--pull=true
--pull=false
--pull=never
--pull=always
For backward compatibility, the --pull-never and --pull-always
options will remain operational, however they are not documented
and are conisdered deprecated.
Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
We need to use the default from containers.conf and not hardcode them in
buildah. This fixes an issue with the cni network backend since it would
try to access /etc/cni/net.d/ even as rootless user. This regression was
introduced in commit f9cff07b81.
Also hide the cni flags as we do not expect users to change this. The
recommended way is to change them in containers.conf.
[NO NEW TESTS NEEDED]
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Add a --all-platforms that instructs the builder to build for the
intersection of all platforms for which the build's base images are
available. Returns an error if any of them aren't references to
manifest lists. We've learned that we can't really trust architecture
and OS information stored in image config blobs, so we don't try to
salvage that case.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
When we're told to add built images to a manifest list, manipulate the
list ourselves, so that if we're creating a list, we won't have a
partially-populated list if some of the builds fail.
This also lets us include all of the platform information (including
variant info, which we can't sniff out after the fact) that we were
given when we started building the images.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Allow ssh socket from host or certain ssh keys to be exposed to a
certain RUN instruction, but not any other instructions, as well as not
showing up in the final image.
This is done by spawining a new agent from buildah and mounting
the listening socket inside the run. SSH_AUTH_SOCK inside the container
will be set to the socket mountpoint. The defualt mountpoint is
/run/buildkit/ssh_agent.{i}
Signed-off-by: Ashley Cui <acui@redhat.com>
Add a pkg/parse.PlatformsFromOptions() which understands a "variant"
value as an optional third value in an OS/ARCH[/VARIANT] argument value,
which accepts a comma-separated list of them, and which returns a list
of platforms.
Teach "from" and "pull" about the --platform option and add integration
tests for them, warning if --platform was given multiple values.
Add a define.BuildOptions.JobSemaphore which an imagebuildah executor
will use in preference to one that it might allocate for itself.
In main(), allocate a JobSemaphore if the number of jobs is not 0 (which
we treat as "unlimited", and continue to allow executors to do).
In addManifest(), take a lock on the manifest list's image ID so that we
don't overwrite changes that another thread might be making while we're
attempting to make changes to it. In main(), create an empty list if
the list doesn't already exist before we start down this path, so that
we don't get two threads trying to create that manifest list at the same
time later on. Two processes could still try to create the same list
twice, but it's an incremental improvement.
Finally, if we've been given multiple platforms to build for, run their
builds concurrently and gather up their results.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Currently the rusage is reported to stdout and rather cumbersome to parse. The
new flag rusage-logfile can be used to specify a file to which the log will be
written instead.
Signed-off-by: Dan Čermák <dcermak@suse.com>
Add support for secrets. Secrets is a two-part flag that allows secret files to
be accessed for a certain RUN instruction, but not any other
instructions, as well as now showing up in the final image.
Signed-off-by: Ashley Cui <acui@redhat.com>
This PR removes the pkg/auth which brings in docker/docker
since it really is not needed, and was only there to help users
discover the settings of where the authfile was, when the environment
variables were set. Would almost never be of any value.
Move imagebuildah.BuildOptions to define.BuildOptions
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We want to shrink the size of the import when importing pkg from
buildah. This should help us shrink the size of the golang bindings
in podman.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Currently manifests just look like images in container storage.
It is surprising to the user when they go to push the images
that they end up failing, and have to use the buildah manifest push.
This patch causes buildah push to failover to buildah manifest push
if the image is a manifest.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Remove --override-os and --override-arch flags.
Also use --platform option if specified when generating the SystemContext.
Conflict --platform option with --os, --arch and --variant options.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Some commands within a Containerfile, might need input from users.
For example confirmation commands from Apt.
Adding a --stdin flag will allows users to interact with containers
while running inside of buildah bud.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
These changes will allow the "FROM" statement in a Containerfile
to be overridden with a new `--from` option. If I have this Dockerfile.fedora
```
FROM fedora
```
This command will instead build an alpine image:
```
STEP 1: FROM alpine
Completed short name "alpine" with unqualified-search registries (origin: /etc/containers/registries.conf)
Getting image source signatures
Copying blob 188c0c94c7c5 done
Copying config d6e46aa247 done
Writing manifest to image destination
Storing signatures
STEP 2: COMMIT tom
--> d6e46aa2470
d6e46aa2470df1d32034c6707c8041158b652f38d2a9ae3d7ad7e7532d22ebe0
```
Addresses: #2404
Signed-off-by: TomSweeneyRedHat <tsweeney@redhat.com>
when running as rootless, make sure the cli default isolation is set
to "rootless" instead of "oci".
Closes: https://github.com/containers/buildah/issues/2750
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Allow users to override location of the .dockerignore file.
If user specified an --ignorefile flag, buildah will read the
file and pass in the exclude lines based on the .dockerignore
contents.
Also add a --contextdir flag to buildah copy and buildah add to
specify where the context directory is located. For these two
commands the --ignorefile flag requires the --contextdir flag.
When the --ignorefile flag is passed in, the .dockerignore files
in the context directory will be ignored.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Jack Wearden
Daniel J Walsh
Aditya R
Ed Santiago
Nalin Dahyabhai
Sascha Grunert
tomsweeneyredhat
Kir Kolyshkin
Paul Holzinger
Kirill Shirinkin
openshift-ci[bot]
Ashley Cui
Dan Čermák
OpenShift Merge Robot
Giuseppe Scrivano