Skip to content
You're viewing an older version of this GitHub Action. Do you want to see the latest version instead?
redhat-actions

GitHub Action

Buildah Build

v2.7

Buildah Build

redhat-actions

Buildah Build

Build a container image, with or without a Containerfile

Installation

Copy and paste the following snippet into your .yml file.

 
              
- name: Buildah Build

              
  uses: redhat-actions/[email protected]
Learn more about this action in redhat-actions/buildah-build

Choose a version

buildah-build

CI checks Build Build from containerfile Link checker

tag badge license badge size badge

Buildah Build is a GitHub Action for building Docker and Kubernetes-compatible images quickly and easily.

Buildah only works on Linux. GitHub's Ubuntu Environments (ubuntu-18.04 and newer) come with buildah installed. If you are not using these environments, or if you want to use a different version, you must first install buildah.

After building your image, use push-to-registry to push the image and make it pullable.

Action Inputs

Inputs for build from containerfile

Input Name Description Default
arch Label the image with this architecture, instead of defaulting to the host architecture. Refer to Multi arch builds for more information. None (host architecture)
build-args Build arguments to pass to the Docker build using --build-arg, if using a Containerfile that requires ARGs. Use the form arg_name=arg_value, and separate arguments with newlines. None
context Path to directory to use as the build context. .
containerfiles* The list of Containerfile paths to perform a build using docker instructions. This is a multiline input to allow multiple Containerfiles. Must be provided
extra-args Extra args to be passed to buildah bud. Separate arguments by newline. Do not use quotes. None
image Name to give to the output image. Must be provided
layers Set to true to cache intermediate layers during the build process. None
oci Build the image using the OCI format, instead of the Docker format. By default, this is false, because images built using the OCI format have issues when published to Dockerhub. false
tags The tags of the image to build. For multiple tags, separate by a space. For example, latest ${{ github.sha }} latest

*The containerfiles input was previously dockerfiles. Now dockerfiles is an alias for containerfiles. For details see the issue.

Inputs for build without containerfile

Input Name Description Default
arch Label the image with this architecture, instead of defaulting to the host architecture. Refer to Multi arch builds for more information. None (host architecture)
base-image The base image to use for the container. Must be provided
content Paths to files or directories to copy inside the container to create the file image. This is a multiline input to allow you to copy multiple files/directories. None
entrypoint The entry point to set for the container. This is a multiline input; split arguments across lines. None
envs The environment variables to be set when running the container. This is a multiline input to add multiple environment variables. None
image Name to give to the output image. Must be provided
oci Build the image using the OCI format, instead of the Docker format. By default, this is false, because images built using the OCI format have issues when published to Dockerhub. false
port The port to expose when running the container. None
tags The tags of the image to build. For multiple tags, separate by a space. For example, latest ${{ github.sha }} latest
workdir The working directory to use within the container. None

Action Outputs

image: The name of the built image.
For example, spring-image.

tags: A list of the tags that were created, separated by spaces.
For example, latest ${{ github.sha }}.

image-with-tag: The name of the image tagged with the first tag present.
For example, spring-image:latest

Build Types

You can configure the buildah action to build your image using one or more Containerfiles, or none at all.

Building using Containerfiles

If you have been building your images with an existing Containerfile, buildah can reuse your Containerfile.

In this case the inputs needed are image and containerfiles. tag is also recommended. If your Containerfile requires ARGs, these can be passed using build-arg.

name: Build Image using Containerfile
on: [push]

jobs:
  build:
    name: Build image
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2

    - name: Buildah Action
      uses: redhat-actions/buildah-build@v2
      with:
        image: my-new-image
        tags: v1 ${{ github.sha }}
        containerfiles: |
          ./Containerfile
        build-args: |
          some_arg=some_value

Building without a Containerfile

Building without a Containerfile requires additional inputs, that would normally be specified in the Containerfile.

Do not set containerfiles if you are doing a build from scratch. Otherwise those Containerfiles will be used, and the inputs below will be ignored.

  • An output image name and usually a tag.
  • base-image
    • In a Containerfile, this would be the FROM directive.
  • content to copy into the new image
    • In a Containerfile, this would be COPY directives.
  • entrypoint so the container knows what command to run.
    • In a Containerfile, this would be the ENTRYPOINT.
  • All other optional configuration inputs, such as port, envs, and workdir.

Example of building a Spring Boot Java app image:

name: Build Image
on: [push]

jobs:
  build-image:
    name: Build image without Containerfile
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2

    - run: mvn package

    - name: Build Image
      uses: redhat-actions/buildah-build@v2
      with:
        base-image: docker.io/fabric8/java-alpine-openjdk11-jre
        image: my-new-image
        tags: v1
        content: |
          target/spring-petclinic-2.3.0.BUILD-SNAPSHOT.jar
        entrypoint: java -jar spring-petclinic-2.3.0.BUILD-SNAPSHOT.jar
        port: 8080

Multi arch builds

Refer to the multi-arch example.

Emulating RUN instructions

Cross-architecture builds from containerfiles containing RUN instructions require qemu-user-static emulation registered in the Linux kernel.

For example, run sudo apt install qemu-user-static on Debian hosts, or sudo dnf install qemu-user-static on Fedora.

You can run a containerized version of the registration if the package does not exist for your distribution:

sudo podman run --rm --privileged docker.io/tonistiigi/binfmt --install all

This registration remains active until the host reboots.

The arch input

The arch argument overrides the Architecture label in the output image. It does not actually affect the architectures the output image will run on. The image must still be built for the required architecture.

There is a simple example in this issue.

Creating a Multi-Arch Image List

Use the buildah manifest command to bundle images into an image list, so multiple image can be referenced by the same repository tag.

There are examples and explanations of the manifest command in this issue.

This action does not support the manifest command at this time, but there is an issue open.

Using private images

If your build references a private image, run podman-login in a step before this action so you can pull the image. For example:

- name: Log in to Red Hat Registry
  uses: redhat-actions/podman-login@v1
  with:
    registry: registry.redhat.io
    username: ${{ secrets.REGISTRY_REDHAT_IO_USER }}
    password: ${{ secrets.REGISTRY_REDHAT_IO_PASSWORD }}