sclorg / build-and-push-action Goto Github PK

License: MIT License

Python 100.00%

build-and-push-action's Introduction

The Build and Push GitHub Action

The action builds a container image and pushes it to the specified registry. The path to upload the image is constructed from inputs as follows:

registry/registry_namespace/image_name

Action Inputs

Registry information

Input Name	Description	Default value
`registry`	Registry to push container image to.	required
`registry_namespace`	Namespace of the registry, where the image would be pushed.	required
`registry_username`	Login to specified registry.	required
`registry_token`	Access token to specified registry.	required

Build information

Input Name	Description	Default value
`image_name`	Name of the built image.	required
`tag`	Tag of the built image.	""
`use_default_tags`	Add default tags to image - SHA, latest, current date	true
`archs`	Label the image with this architecture. For multiple architectures, seperate them by a comma.	amd64
`dockerfile`	Dockerfile and its relative path to build the image.	Dockerfile
`docker_context`	Docker build context.	.

Other information

Input Name	Description	Default value
`readme`	If path to readme is set, the readme is updated to the registry. Only quay.io is supported.	""
`quay_application_token`	Application token is used for updating description for image.	""

Example

The example below shows how the sclorg/build-and-push-action can be used.

name: Build and push to quay.io registry
on:
  push:
    branches:
      - main

jobs:
  build-and-push:
    runs-on: ubuntu-20.04
    steps:
      - name: Build and push to quay.io registry
        uses: sclorg/build-and-push-action@v2
        with:
          registry: "quay.io"
          registry_namespace: "namespace"
          registry_username: ${{ secrets.REGISTRY_LOGIN }}
          registry_token: ${{ secrets.REGISTRY_TOKEN }}
          dockerfile: "1.20/Dockerfile"
          image_name: "container_image-1.20"
          tag: "tag"

Multi arch builds

Input archs is provided to build the multi architecture images. archs input should be comma separated ( i.e. archs: "amd64, s390x" ). It is an optional argument, if not provided image will be built on amd64 i.e. default arch

The example below shows how the sclorg/build-and-push-action can be used for multi-arch image

name: Build and push to quay.io registry
on:
  push:
    branches:
      - main

jobs:
  build-and-push:
    runs-on: ubuntu-20.04
    steps:
      - name: Build and push to quay.io registry
        uses: sclorg/build-and-push-action@v2
        with:
          registry: "quay.io"
          registry_namespace: "namespace"
          registry_username: ${{ secrets.REGISTRY_LOGIN }}
          registry_token: ${{ secrets.REGISTRY_TOKEN }}
          dockerfile: "1.20/Dockerfile"
          image_name: "container_image-1.20"
          tag: "tag"
          archs: "amd64, s390x"

build-and-push-action's People

Contributors

Watchers

Forkers

zmiklank phracek modassarrana89 jcho02

build-and-push-action's Issues

Consider adding outputs to this action

Add step for updating description in Quay.io

The script for this is already written:
https://github.com/sclorg/ci-scripts/blob/master/jenkins_ci/update_quay_description.py

We just need to call it in the build-and-push action.

Do not generate files with distgen

The files should be already correctly generated in the git repository.

This should be implemented only after we have some check, that the files are regenerated properly and are up to date.
I will then start working on this.

CC: @pkubatrh @frenzymadness @phracek

Add flag with commit hash to built images

Currently, we pass github.sha to buildah, to create image with this tag.
However, we use also "latest" tag and tag with current date.

That means, that if user pulls the image via other then sha tag, it will no longer be possible to get the commit hash from the image.

We should consider adding some information about hash of the latest commit to the released images.

What is the resulting image name: opportunity to improve transparency

It took me a while and a look into the code to realize what the resulting image actually is, because it's composed from more parts, each part coming from a different source:

        image: ${{ steps.base-image-name.outputs.image_name}}-${{ steps.clean_path.outputs.clean_dockerfile_path }}${{ steps.suffix_name.outputs.suffix }}

I think that improving transparency on the expense of more duplication here might be not that bad idea, which means the specification would simply include the resulting name. One of the possible implementation might be adding something like "output_image" key, which might make some of the other keys not needed (didn't check), e.g.:

         - dockerfile_path: "18"
           dockerfile: "Dockerfile.fedora"
           registry_namespace: "fedora"
           tag: "fedora"
           output_image: "quay.io/fedora/nodejs-18"
           quayio_username: "QUAY_IMAGE_FEDORA_BUILDER_USERNAME"
           quayio_token: "QUAY_IMAGE_FEDORA_BUILDER_TOKEN"