redhat-actions / buildah-build

GitHub Action to use 'buildah' to build a container image.
https://github.com/marketplace/actions/buildah-build
MIT License
137 stars 35 forks source link

[FEATURE] Compatibility with docker/metadata-action #74

Closed ntkme closed 2 years ago

ntkme commented 2 years ago

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:

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 }}
divyansh42 commented 2 years ago

We have released this feature in v2.8 However, you should be able to use this in buildah-build@v2 also.