I think it would be useful to output the image name (including tag), so it could be used by subsequent steps and would not have to be hard-coded in both steps.

The UnhandledPromiseRejection means there is a missing await, or there is a top-level catch block missing.

In the PR #75 we added support for platform but it seems --platform flag is only available for buildah bud command.
Therefore when using --platform with buildah config command it fails with error unknown flag.

Failed workflow: https://github.com/divyansh42/buildah-build/runs/3923850206?check_suite_focus=true#step:11:90

It seems buildah docs links are updated, this needs to be changed at few places in README.
Ref: https://github.com/redhat-actions/buildah-build/runs/3773371974?check_suite_focus=true#step:4:83

Similar to redhat-actions/push-to-registry#38, as push-to-registry action uses output from this action.
So, this behaviour should be present in this action too.

Proper documentation needs to be done for this.

I'm unable to build a image using the buildah-build action, when my containerfile is based on image from registry.redhat.io

STEP 1: FROM registry.redhat.io/ubi8/ubi:latest
error creating build container: Error initializing source docker://registry.redhat.io/ubi8/ubi:latest: unable to retrieve auth token: invalid username/password: unauthorized: Please login to the Red Hat Registry using your Customer Portal credentials. Further instructions can be found here: https://access.redhat.com/RegistryAuthentication
level=error msg="exit status 125"
Error: Error: buildah exited with code 125
error creating build container: Error initializing source docker://registry.redhat.io/ubi8/ubi:latest: unable to retrieve auth token: invalid username/password: unauthorized: Please login to the Red Hat Registry using your Customer Portal credentials. Further instructions can be found here: https://access.redhat.com/RegistryAuthentication
level=error msg="exit status 125"

Is your feature request related to a problem? Please describe.

When we update the heading text then links to that heading breaks

Describe the solution you'd like

If we add anchor to the link then change in heading text won't be a breaking change

Hi, I was pointed to:

Question

The current buildah version installed in the action image, 1.21.3, does not support using both digest and tag in an image reference in the Dockerfile:

/usr/bin/buildah version
  /usr/bin/buildah version
  Version:         1.21.3
  Go Version:      go1.15.2
  Image Spec:      1.0.1-dev
  Runtime Spec:    1.0.2-dev
  CNI Spec:        0.4.0
  libcni Version:  
  image Version:   5.12.0
  Git Commit:      
  Built:           Thu Jan  1 00:00:00 1970
  OS/Arch:         linux/amd64
Overriding storage mount_program with "fuse-overlayfs" in environment
Performing build from Containerfile
/usr/bin/buildah bud -f /home/runner/work/festoji/festoji/Dockerfile --format docker -t lucarval/festoji:latest /home/runner/work/festoji/festoji
STEP 1: FROM registry.redhat.io/rhel8/go-toolset:latest@sha256:db74be244cbf62081667253dbafeb0af75c3410982a45767d1dca6a3eb86f49b AS builder
STEP 2: FROM scratch
error creating build container: Invalid image name "registry.redhat.io/rhel8/go-toolset:latest@sha256:db74be244cbf62081667253dbafeb0af75c3410982a45767d1dca6a3eb86f49b", unknown transport "registry.redhat.io/rhel8/go-toolset"
time="2021-10-07T18:00:40Z" level=error msg="exit status 125"
Error: Error: buildah exited with code 125

I have 1.23.0 installed locally which seems to have this support:

$ buildah --version
buildah version 1.23.0 (image-spec 1.0.1-dev, runtime-spec 1.0.2-dev)

$ buildah bud -t test:latest .
[1/2] STEP 1/4: FROM registry.redhat.io/rhel8/go-toolset:latest@sha256:db74be244cbf62081667253dbafeb0af75c3410982a45767d1dca6a3eb86f49b AS builder
[1/2] STEP 2/4: WORKDIR /opt/app-root/src
[1/2] STEP 3/4: COPY . .
[1/2] STEP 4/4: RUN go build -o bin/festoji main.go
go: downloading gopkg.in/yaml.v2 v2.4.0
[2/2] STEP 1/3: FROM scratch
[2/2] STEP 2/3: COPY --from=builder /opt/app-root/src/bin/festoji /usr/bin/festoji
[2/2] STEP 3/3: CMD ["festoji"]
[2/2] COMMIT test:latest
Getting image source signatures
Copying blob d91142b714ec done  
Copying config 04f22b04d0 done  
Writing manifest to image destination
Storing signatures
--> 04f22b04d04
Successfully tagged localhost/test:latest
04f22b04d04a502bec314ea611fc141b6fe19b3f2789722a840296aab3913e41

I think simply updating the buildah version used in the action image should do the trick because 1.23.0 is already released in opensuse: https://software.opensuse.org/package/buildah

Is your feature request related to a problem? Please describe.

I encountered a few issues when using multi-architecture support:

1. The docker image for sudo podman run --rm --privileged multiarch/qemu-user-static --reset -p yes is available from the docker.io registry, but the registry prefix is missing in the command. It now shows an error message (Ubuntu 21.04) or asks which registry to use (CentOS 8).
2. The current README assumes that the host is running amd64 architecture. This assumption is not correct when using self-hosted runner applications for arm64 and arm32 architectures.
3. The multiarch/qemu-user-static image is only available for the amd64 architecture. A multi-architecture image would be preferred instead.
4. It seems that QEMU and binfmt support is only needed for multi-arch builds from dockerfiles that do contain RUN instructions. buildah run is not called by this action. Using qemu-user-static for other builds might unnecessary slow them down and consume additional bandwidth.
5. The Multi arch builds section talks about installing qemu-user-static. The word install suggests that the changes are still present after a reboot of the host machine. However, this process should be repeated after each reboot.

Describe the solution you'd like

1. Use sudo podman run --rm --privileged docker.io/multiarch/qemu-user-static --reset -p yes instead, which includes the docker.io prefix.
2. Any reference to amd64 should be replaced by host architecture.
3. Use sudo podman run --rm --privileged docker.io/tonistiigi/binfmt --install all because it supports 8 different host architectures. The same image is also used by docker/setup-qemu-action
4. In the Inputs for build without dockerfile section, remove the reference to Multi arch builds. In the Multi arch builds section, describe that qemu-user-static is only needed when RUN instructions are used in dockerfiles.
5. Describe that the process must be repeated after rebooting the host machine. Or suggest to run sudo apt install -y qemu-user-static.

Describe alternatives you've considered

3. sudo podman run --rm --privileged docker.io/aptman/qus -s -- -p could also be an option

Additional context

1. Error on Ubuntu 21.04: error getting default registries to try: short-name "multiarch/qemu-user-static" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"
3. Error: {"msg":"exec container process /register: Exec format error","level":"error","time":"2021-06-14T12:23:06.000446093Z"}

Version v2

Describe the bug

Attempting to use buildah-build action but having a problem with getting the copy command to honor the workdir.
My action looks like:

    # Build container image without Dockerfile!
    - name: Build container image using Buildah 
      uses: redhat-actions/buildah-build@v2
      with:
        image:  ${{env.acrsite}}/${{env.repo}}
        tags: ${{github.run_number}} ${{ github.sha }}
        workdir: /app/
        build-args: |
          build_version=${{github.run_number}}
        base-image: mcr.microsoft.com/dotnet/aspnet:2.1
        entrypoint: |
          dotnet
          poi.dll
        envs: |
          WEB_PORT="8080"
          WEB_SERVER_BASE_URI="http://0.0.0.0"
          ASPNETCORE_ENVIRONMENT="Production"
        content: |
          myapp

What's happening is that the content from my local myapp directory is being copied into the root of the image, rather than into the /app workdir. I have tried setting workdir to /app and /app/, but in both cases, the content is copied into the root, not into the workdir. I do see that the '/app' directory was created; it's just not being used.

When looking at the run, it appears that the copy command is happening before the build config command with the workdir argument, so I think this is the cause of the problem:

Overriding storage mount_program with "fuse-overlayfs" in environment
Performing build from scratch
/usr/bin/buildah from mcr.microsoft.com/dotnet/aspnet:2.1
Trying to pull mcr.microsoft.com/dotnet/aspnet:2.1...
Getting image source signatures
Copying blob sha256:33f99cea3b7da8c6e0143c9fd7590c6d56f7d310ddd59b11be4ad485ae4cab2a
Copying blob sha256:f66af433fc3eabe3694f2bd46f6936aadb99adf45275e78b5e46894149829642
Copying blob sha256:2b463c1ef5a97bea188f214519fec9d82d0e411e6d47685262df4098a5fad185
Copying blob sha256:06e05c6a34c19717d50d6de009d20a269e522e8cfef2949c1e26b74dc0bf841b
Copying config sha256:1a48139335f865314e13afee3978a53d3bc6adf3b1b3f4543eb6742a4a07db1a
Writing manifest to image destination
Storing signatures
aspnet-working-container
/usr/bin/buildah copy aspnet-working-container myapp
243190cfec4ce2dc69cf717980cc2fa87b3a111eee0f6e70b998d505515fee88
/usr/bin/buildah config --entrypoint ["dotnet","poi.dll"] --env WEB_PORT="8080" --env WEB_SERVER_BASE_URI="http://0.0.0.0" --env ASPNETCORE_ENVIRONMENT="Production" --workingdir /app/ aspnet-working-container
time="2021-09-01T17:37:34Z" level=warning msg="cmd \"bash\" exists and will be passed to entrypoint as a parameter"
/usr/bin/buildah commit --format docker --squash aspnet-working-container [....]/api-poi:39

Steps to reproduce, workflow links, screenshots

see above

Version

redhat-action/buildah-build@v2

Describe the bug

Using archs: amd64,arm64 I expect it to build amd64 & arm64 images (like the docs state), but the command that is run is incorrect according to the buildah docs (--arch takes only one argument but it is given two)

Steps to reproduce, workflow links, screenshots

https://github.com/vilgotf/voice-pruner/runs/3013577143

Is your feature request related to a problem? Please describe.

I'm trying to do a base image build using buildah, but need to fetch the source image from an internal registry without valid certificate (internal k8s registry)

Describe the solution you'd like

buildah from have a the possibility of extra arguments, including --tls-verify.
This action does not seem to pass extra-args when doing a base image build.

Question

https://devops.stackexchange.com/questions/13524/how-can-i-use-a-buildah-script-for-image-generation-using-github-actions

Buildah scripts typically use shell. You can see an example of a script here,

#!/bin/sh
ctr=$(buildah from alpine:3)
buildah commit "$ctr" myAlpineImage

Let's say I have such a shell script that produces an image "myAlpineImage". How can I use GitHub CI to automate the creation of this image, and preferably uploading it to GitHub Container Registry?

Similar to redhat-actions/push-to-registry#51

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

As a developer using buildah and podman in RedHat's GitHub Actions, I would like the actions to lowercase the image name and tag name, as required by registry specifications, lest the images and tags will be rejected. Unlike CLI operation, GitHub Actions that store images in GitHub Container Registry can and will reference image names from org and repo names with capital letters, so using this action with or independently without the push-to-registry will cause problems.

See redhat-actions/push-to-registry#56 for more details. I will draft a PR to provide similar functionality in this action, as the lack of that feature blocks integration testing and practical use.

Describe alternatives you've considered

See comments in redhat-actions/push-to-registry#56.

As the buildah tekton task, this action should support building from Dockerfiles, using its buildah bud command. This command executes the directives in the Dockerfile to assemble a container image.

At present, we have test workflows for multi-arch that only test building from containerfile, we should try and add some tests for the build from scratch.

I think info level is best, at the top of the workflow. Warning level is too annoying.

Do the same for push-to-registry

Presently manifest is created if input archs or platform is provided even if these inputs contain only one value.
We should skip manifest creation if only one arch or platform is provided.

Question

Hi, I've seen an interesting trick at https://github.com/pyca/infra/blob/d52c449/.github/workflows/build-docker-images.yml#L58 where they use docker build --cache-from=... to have Docker reuse some of the layer cache from an earlier image version IIUC.

When I saw #43 / #42, I thought — would it be possible to do the same with podman/buildah? What would be required? Would podman pull coupled with layers: true be enough? Is there something I'm misunderstanding in how buildah works? (there probably is)

I know that podman's --cache-from is no-op but I thought maybe it is possible to achieve somehow on the buildah level?

Version

Run redhat-actions/buildah-build@v2
/usr/bin/buildah version
Version: 1.20.0
Go Version: go1.15.2
Image Spec: 1.0.1-dev
Runtime Spec: 1.0.2-dev
CNI Spec: 0.4.0
libcni Version:
image Version: 5.10.5

Describe the bug

Hello,
After the upgrade to 1.20.0 I can't build a simple python.
It seems that docker.io has been removed from the registry.conf and some permission issue is happening

Working build - https://github.com/gfvirga/http-liveness/runs/2242528975?check_suite_focus=true
Can't find python - https://github.com/gfvirga/http-liveness/runs/2250342456?check_suite_focus=true
Tar error - https://github.com/gfvirga/http-liveness/runs/2250371480?check_suite_focus=true

I am using the default agent from github.

Steps to reproduce, workflow links, screenshots

Run redhat-actions/buildah-build@v2
/usr/bin/buildah version
Version:         1.20.0
Go Version:      go1.15.2
Image Spec:      1.0.1-dev
Runtime Spec:    1.0.2-dev
CNI Spec:        0.4.0
libcni Version:  
image Version:   5.10.5
Git Commit:      
Built:           Thu Jan  1 00:00:00 1970
OS/Arch:         linux/amd64
Performing build from Dockerfile
/usr/bin/buildah bud --arch amd64 -f /home/runner/work/http-liveness/http-liveness/Dockerfile --format docker -t gfvirga/httpliveness:latest /home/runner/work/http-liveness/http-liveness
STEP 1: FROM python
Resolving "python" using unqualified-search registries (/etc/containers/registries.conf)
Getting image source signatures
Copying blob sha256:234b70d0479d7f16d7ee8d04e4ffdacc57d7d14313faf59d332f18b2e9418743
Copying blob sha256:04a31b4508b8e95fb3cb25486c4068185054895b12e0611e386a002ee9c0e07c
Copying blob sha256:6fa07a00e2f029c4b2c7f177a2b696f1b3510040cde4f5bb06ddbca98e7fbf76
Copying blob sha256:5d6f1e8117dbb1c6a57603cb4f321a861a08105a81bcc6b01b0ec2b78c8523a5
Copying blob sha256:004f1eed87df3f75f5e2a1a649fa7edd7f713d1300532fd0909bb39cd48437d7
Copying blob sha256:48c2faf66abec3dce9f54d6722ff592fce6dd4fb58a0d0b72282936c6598a3b3
Copying blob sha256:2eee1b8e253830859988454f07e1e98387cf5e3730e7eedee333aa7fd1a04be2
Copying blob sha256:1823d93d969893b61303752fa11b710c4befae6f15a775fad2c2c0bcb619cf2e
Copying blob sha256:b48672c0140e5d73a8b044e4c1c229f3cc88fd8ff645c7fc6f774c830ae1f8d4
Copying config sha256:587b1bc803b36f65923fe677467bb619b4e464d7f988377bb5c6c0a26eef044d
Writing manifest to image destination
Storing signatures
error creating build container: 2 errors occurred while pulling:
 * Error committing the finished image: error adding layer with blob "sha256:5d6f1e8117dbb1c6a57603cb4f321a861a08105a81bcc6b01b0ec2b78c8523a5": Error processing tar file(exit status 1): operation not permitted
 * Error initializing source docker://quay.io/python:latest: Error reading manifest latest in quay.io/python: StatusCode: 404, <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final/...
level=error msg="exit status 125"
Error: Error: buildah exited with code 125
Resolving "python" using unqualified-search registries (/etc/containers/registries.conf)
Getting image source signatures
Copying blob sha256:234b70d0479d7f16d7ee8d04e4ffdacc57d7d14313faf59d332f18b2e9418743
Copying blob sha256:04a31b4508b8e95fb3cb25486c4068185054895b12e0611e386a002ee9c0e07c
Copying blob sha256:6fa07a00e2f029c4b2c7f177a2b696f1b3510040cde4f5bb06ddbca98e7fbf76
Copying blob sha256:5d6f1e8117dbb1c6a57603cb4f321a861a08105a81bcc6b01b0ec2b78c8523a5
Copying blob sha256:004f1eed87df3f75f5e2a1a649fa7edd7f713d1300532fd0909bb39cd48437d7
Copying blob sha256:48c2faf66abec3dce9f54d6722ff592fce6dd4fb58a0d0b72282936c6598a3b3
Copying blob sha256:2eee1b8e253830859988454f07e1e98387cf5e3730e7eedee333aa7fd1a04be2
Copying blob sha256:1823d93d969893b61303752fa11b710c4befae6f15a775fad2c2c0bcb619cf2e
Copying blob sha256:b48672c0140e5d73a8b044e4c1c229f3cc88fd8ff645c7fc6f774c830ae1f8d4
Copying config sha256:587b1bc803b36f65923fe677467bb619b4e464d7f988377bb5c6c0a26eef044d
Writing manifest to image destination
Storing signatures
error creating build container: 2 errors occurred while pulling:
 * Error committing the finished image: error adding layer with blob "sha256:5d6f1e8117dbb1c6a57603cb4f321a861a08105a81bcc6b01b0ec2b78c8523a5": Error processing tar file(exit status 1): operation not permitted
 * Error initializing source docker://quay.io/python:latest: Error reading manifest latest in quay.io/python: StatusCode: 404, <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final/...
level=error msg="exit status 125"

This action repo needs a workflow which builds an image, which can be used as a test-case as well as an example.

This action is lacking the testing mechanism. If there is some update in code or new feature got added that may contain few bugs.
So to ensure the changes being done is as desired, a testing mechanism would be helpful.

Version

redhat-actions/[email protected]

Describe the bug

First of all documentation is misleading in this part:

The archs and platforms arguments override the Architecture and Platform labels in the output image, respectively. They do not actually affect the architectures and platforms the output image will run on. The image must still be built for the required architecture or platform.

They do actually affect the architectures and platforms the output image will run on. Here comes the actual issue I want to report. They do affect but in case base image does not exist for the desired non-native target architectures, then the build succeeds, labels are fine, just all generated images are for the native platform without any warning or error.

I think it serves users much better to fail when base image for the target platform is missing. This will reduce confusion and make debugging process much quicker.

Steps to reproduce, workflow links, screenshots

Workflow 1 with a base image with all target architectures:

...
STEP 2/3: RUN uname -a && echo && env
time="2022-07-01T09:54:53Z" level=warning msg="Failed to decode the keys [\"machine\"] from \"/usr/share/containers/containers.conf\"."
Linux 7db1804db6ae 5.13.0-1031-azure #37~20.04.1-Ubuntu SMP Mon Jun 13 22:51:01 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
...
STEP 2/3: RUN uname -a && echo && env
time="2022-07-01T09:55:02Z" level=warning msg="Failed to decode the keys [\"machine\"] from \"/usr/share/containers/containers.conf\"."
Linux c8f0c044e788 5.13.0-1031-azure #37~20.04.1-Ubuntu SMP Mon Jun 13 22:51:01 UTC 2022 s390x s390x s390x GNU/Linux
...
 STEP 2/3: RUN uname -a && echo && env
time="2022-07-01T09:55:12Z" level=warning msg="Failed to decode the keys [\"machine\"] from \"/usr/share/containers/containers.conf\"."
Linux 1b0c3fce6405 5.13.0-1031-azure #37~20.04.1-Ubuntu SMP Mon Jun 13 22:51:01 UTC 2022 ppc64le ppc64le ppc64le GNU/Linux
...

Workflow 2 with base image that has only amd64 arch:

...
STEP 2/3: RUN uname -a && echo && env
time="2022-07-01T10:15:54Z" level=warning msg="Failed to decode the keys [\"machine\"] from \"/usr/share/containers/containers.conf\"."
Linux 2ebf20e578e0 5.13.0-1031-azure #37~20.04.1-Ubuntu SMP Mon Jun 13 22:51:01 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
...
 STEP 2/3: RUN uname -a && echo && env
time="2022-07-01T10:16:18Z" level=warning msg="Failed to decode the keys [\"machine\"] from \"/usr/share/containers/containers.conf\"."
Linux 2ebf20e578e0 5.13.0-1031-azure #37~20.04.1-Ubuntu SMP Mon Jun 13 22:51:01 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
...
 STEP 2/3: RUN uname -a && echo && env
time="2022-07-01T10:16:31Z" level=warning msg="Failed to decode the keys [\"machine\"] from \"/usr/share/containers/containers.conf\"."
Linux 2ebf20e578e0 5.13.0-1031-azure #37~20.04.1-Ubuntu SMP Mon Jun 13 22:51:01 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
...

Same way we do with podman version in PTR

Is your feature request related to a problem? Please describe.

docker/metadata-action provides a way to infer tag names and labels from git metadata. It's very convenient in terms of creating semantic versioning image tags automatically whenever a git tag is created. e.g. git tag v1.2.3 becomes container tags 1, 1.2, 1.2.3.

The compatibility issue comes from that redhat-actions/buildah-build and redhat-actions/push-to-registry handle image names and tags input differently from docker's actions.

In summary:

• docker action takes a list of tags in the canonical form of image:tag.
• buildah action takes a single image and a list of tag names as only the tag part, and then different image prefix (namespace) need to be specified in the push action.

In additional there is also a problem with pushing the same image to different image names in the current model. Docker action's model is more flexible here, for example, podman's official image has two different image names: quay.io/containers/podman:<version>, quay.io/podman/stable:<version>. If we attempt to build and push both image names, the docker action approach would be much more convenient as user just need to specify two image:tag in the canonical format (see example action.yml attached below). However, with current buildah action, we will have to manually add a step to create a tag alias, and then run push action twice.

Describe the solution you'd like

The preferred solution is to changing the image name / tag name input behavior to align with docker's actions. In terms of implementation, image input would become optional. If image input it not provided, tags inputs must be specified in canonical form of image:tag. This way it can be backwards compatible with existing workflows.

Describe alternatives you've considered

Create a podman-metadata action that is similar to docker metadata action, but output only one image name and multiple tags in separate fields. However, this is way less ideal for the use case of pushing different image names I mentioned previously. Also the development and maintenance cost is probably not worth it.

Additional context

Here is an example using docker/metadata-action:

name: build

on:
  push:
    branches:
      - '**'
    tags:
      - 'v*.*.*'
  pull_request:
    branches:
      - '**'

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' || github.actor == 'dependabot[bot]' }}

jobs:
  build:
    name: Build

    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Docker Metadata
        id: docker-metadata
        uses: docker/metadata-action@v3
        with:
          images: |
            quay.io/containers/podman
            quay.io/podman/stable
          tags: |
            type=edge
            type=ref,event=branch
            type=ref,event=pr
            type=schedule
            type=semver,pattern={{version}}
            type=semver,pattern={{major}}.{{minor}}
            type=semver,pattern={{major}},enable=${{ !startsWith(github.ref, 'refs/tags/v0.') }}

      - name: Set up QEMU
        uses: docker/setup-qemu-action@v1

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v1

      - name: Login to Quay Container Registry
        uses: docker/login-action@v1
        with:
          registry: quay.io
          username: ${{ github.actor }}
          password: ${{ secrets.QUAY_TOKEN }}

      - name: Build and push
        uses: docker/build-push-action@v2
        with:
          context: .
          platforms: linux/amd64,linux/arm64
          push: ${{ github.event_name != 'pull_request' && github.actor != 'dependabot[bot]' }}
          tags: ${{ steps.docker-metadata.outputs.tags }}
          labels: ${{ steps.docker-metadata.outputs.labels }}

Version

redhat-actions/[email protected]

Describe the bug

$sbj. README says to use https://github.com/marketplace/actions/docker-setup-qemu but that does not work (I don't have a log anymore but it said something about the wrong architecture when I tried to build AARCH64 with archs: linux/arm64 set).

I managed to make it work by using

- name: >-
    Set up QEMU ${{ matrix.IMAGE.QEMU_ARCH }} arch emulation
    with Podman
  if: matrix.IMAGE.QEMU_ARCH == 'arm64'
  run: >-
    sudo podman run
    --rm --privileged
    multiarch/qemu-user-static
    --reset -p yes

I think it's worth documenting in README. And as a bonus, maybe it's worth wrapping this as an action mirroring docker/setup-qemu-action to encapsulate this command similar to other related actions.

Or maybe detect what the users set in the archs input and do this implicitly in this action.

Steps to reproduce, workflow links, screenshots

https://github.com/ansible/pylibssh/blob/7219ac6/.github/workflows/build-manylinux-container-images.yml

Version

redhat-actions/buildah-build@v2

Describe the bug

(I'm a noob and it's probably my fault)

setting oci: true in the workflow runs buildah bud and not buildah build anyway

Steps to reproduce, workflow links, screenshots

name: Test image

on:
 pull_request:

jobs:
  test_build:
    name: test build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: redhat-actions/buildah-build@v2
        with:
          image: test-image
          tags: v1 ${{ github.sha }}
          oci: true
          containerfiles: |
            ./build.sh

Run redhat-actions/buildah-build@v2
/usr/bin/buildah version
Overriding storage mount_program with "fuse-overlayfs" in environment
Performing build from Containerfile
/usr/bin/buildah bud -f /home/runner/work/flutter_development_container/flutter_development_container/build.sh --format oci -t test-image:v1 /home/runner/work/flutter_development_container/flutter_development_container
no FROM statement found
time="2021-10-11T19:14:36Z" level=error msg="exit status 125"
Error: Error: buildah exited with code 125
no FROM statement found
time="2021-10-11T19:14:36Z" level=error msg="exit status 125"

if you want to look at the repo here is the link,
I'm really new to devops stuff so please understand
(also if you want to help me out I'd be very happy :) )

We should allow multiple inputs for port and rename it to ports.

Like we have in push-to-registry, it would be useful to have an output that contains the built image's digest.

Version

Describe the bug

Steps to reproduce, workflow links, screenshots

We should support tokens as well as username/password.

I often find myself concatenating the image and tag outputs.

We should add another output which contains this value since it's common to use in subsequent steps.

If there are multiple tags, just use the first one, because they all refer to the same image.

Like we are adding with podman/PTR we should have a test case that installs the very newest buildah release so we can test it before it is added to the GitHub runners.

In the code input workDir is not used at all. This should be used in building image without Dockerfile.
and according to README, input context is applicable for building image without Dockerfile, but it shouldn't be there (as buildah doesn't have anything like context for non Dockerfile build).

If a user wants to publish multiple images under one index, eg when building multi-arch images, the 'manifest' command is used to bundle the images together.

#60
https://github.com/containers/buildah/blob/main/docs/buildah-manifest.1.md
containers/buildah#1590

The --layers option is useful in buildah when given a persistent disk, but not useful in CI systems where the disk is discarded after each job

Since we've verified this option allows caching to work in the self-hosted buildah runner we should add an input for it

To keep with buildah behaviour, it should be false by default.

In addition, it may make sense to set export BUILDAH_LAYERS=true into the runner.

Looks like the buildah can build multi-arch images: containers/buildah#1590
Can we use it in this action?

Add support for the platform option

as per #24 (comment)

Question

Hello, thank you for this action, it's marvelous.
Today our builds started to fail and I'm wondering what's changed and where can be the cause.

Writing manifest to image destination
Storing signatures
level=error msg="error unmounting /home/runner/.local/share/containers/storage/overlay/0781b6291aebaf9c44638d47503ccc8967e46e541203bd35d79bef4a0566b5ac/merged: invalid argument"
error mounting new container: error mounting build container "b11e0c122471549c9c260843257e96e91b92ed343041b40f9f119667b6979a0f": error creating overlay mount to /home/runner/.local/share/containers/storage/overlay/0781b6291aebaf9c44638d47503ccc8967e46e541203bd35d79bef4a0566b5ac/merged, mount_data=",lowerdir=/home/runner/.local/share/containers/storage/overlay/l/JVFKZCGLHI42F7Y324TMXFQZ4P:/home/runner/.local/share/containers/storage/overlay/l/3PUMEEVI6PIVBZDO2HZF7SXLWO,upperdir=/home/runner/.local/share/containers/storage/overlay/0781b6291aebaf9c44638d47503ccc8967e46e541203bd35d79bef4a0566b5ac/diff,workdir=/home/runner/.local/share/containers/storage/overlay/0781b6291aebaf9c44638d47503ccc8967e46e541203bd35d79bef4a0566b5ac/work,userxattr": invalid argument
level=error msg="exit status 125"

The only difference between the failing one and 20hours old passing previous one I see in logs is the buildah version
1.19.8 (previous, OK) vs. 1.20.0 (failed).

I know it's most likely not your fault, that's why I'm creating a question in case someone else also hits this.

Is your feature request related to a problem? Please describe.

When building multi-arch image with buildx (docker/build-push-action@v2), builds complete much quicker than with redhat-actions/buildah-build@v2.

It seems to me that buildx action performs builds in parallel and this saving significant time from the builds. As an example, my multi-arch build with buildx takes 41 minutes and with buildah - 1h36m

Describe the solution you'd like

build images in parallel and provide a configuration option to run in sequence when desired.

ie if you do buildah bud -f Containerfile ./my-buildah-dir then it should look for the containerfile at ./my-buildah-dir/Containerfile

for some reason, absolute paths are used https://github.com/redhat-actions/buildah-build/blob/main/src/index.ts#L61

containers/buildah@bee0a1f
Basically, it can be confirmed that the TARGETPLATFORM variable of buildah earlier than 1.26.0 is faulty.
But even the buildah version in the Ubuntu 22.04 software source is only 1.23.1.
This is obviously not enough, so I tried to install a higher version of buildah, but encountered difficulties.
actions/runner-images#2703 (comment)

sudo apt-get install -y buildah -o Dpkg::Options::="--force-overwrite"
But I'm lucky. This order works.
However, it may be necessary to inform this fault in the document.

Examples.
$ buildah build --platform linux/arm64 .

FROM --platform=$BUILDPLATFORM alpine
ARG TARGETPLATFORM
ARG BUILDPLATFORM
RUN echo "I'm compiling for $TARGETPLATFORM on $BUILDPLATFORM and tagging for $TARGETPLATFORM"

Wrong output.
I'm compiling for linux/amd64 on linux/amd64 and tagging for linux/amd64

Correct output.
I'm compiling for linux/arm64 on linux/amd64 and tagging for linux/arm64

The readme demos/docu of this action use the v1 tag in combination with the tags option, but that was introduced in v2 (tag was renamed to tags).

Is your feature request related to a problem? Please describe.

I want to have a shorter workflow file and skip checkout step when all needed is to just checkout source from current event.

For example with buildx I can have:

...
      - name: Build and push Docker image
        id: build-and-push
        uses: docker/build-push-action@v2
        with:
          push: ${{ github.event_name != 'pull_request' }}
          tags: ${{ steps.meta.outputs.tags }}
          platforms: ${{ inputs.platforms }}
          labels: ${{ steps.meta.outputs.labels }}
          file: openshift/system/Dockerfile

With buildah I need to do:

- uses: actions/checkout@v3

- name: Build image
    id: build-image
    uses: redhat-actions/buildah-build@v2
    ...

Describe the solution you'd like

Checkout to happen automatically.

In line with redhat-actions/push-to-registry#6 this action should allow multiple tags. Then, the image output is tagged with all the tags given.

I prefer a space-delimited input, though I know this action was originally written with new-line delimited "multi" inputs

The readme states:

if you are not using those Ubuntu environments you need to make sure to install buildah tool in an early step.

We have to give users some direction on how to install buildah onto their linux runners.

Presently, if there is some option the user wants to pass to buildah that we don't have an input for, they are out of luck.

Tekton solves this problem with an "extra args" option that the user can put any extra args they like into and they are just appended to the buildah command.

https://github.com/tektoncd/catalog/blob/master/task/buildah/0.2/buildah.yaml

OCI projects prefer the generic term 'containerfile' over 'dockerfile'.

We should, where we can, replace 'dockerfile' with the generic variant.

currently we have an input called 'dockerfiles'. We don't want to rename that since it would break workflows - but we can add a containerfiles input which is an alias to dockerfiles. Then we can use containerfiles in workflows, if preferred.