-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create and publish container images from this repository #912
Conversation
c8b6cac
to
ea842b8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Every time I code something non-obvious, colleagues ask me why. Now it's my turn:
@oxzi Please take another look. I have left the conversations open so that you can close them if you agree with the changes. |
@oxzi I have removed the test code and included all changes. Please take another look. |
For reference, this is code required to run build provenance attestation for untagged images: diff --git a/.github/workflows/container-image.yml b/.github/workflows/container-image.yml
index 9bbc94a4..1a56a74a 100644
--- a/.github/workflows/container-image.yml
+++ b/.github/workflows/container-image.yml
@@ -37,6 +37,11 @@ jobs:
attestations: write
id-token: write
+ # TODO (el): This is a temporary setup; see the details in the "Build and push Container image" section.
+ strategy:
+ matrix:
+ platform: [linux/amd64, linux/arm64]
+
steps:
- name: Extract metadata (tags, labels)
id: meta
@@ -86,8 +91,23 @@ jobs:
with:
file: ./Containerfile
labels: ${{ steps.meta.outputs.labels }}
- platforms: linux/amd64,linux/arm64
push: ${{ github.event_name != 'pull_request' }}
+ # TODO (el): The use of load and matrix.platform is a temporary setup for
+ # testing signed build provenance attestations for containers.
+ # Since attestations are only required when images are actually pushed,
+ # both can be removed once we add `if: ${{ github.event_name != 'pull_request' }}` and
+ # `push-to-registry: true` to the relevant steps.
+ #
+ # The docker/setup-buildx-action@v3 uses the docker-container driver by default,
+ # which keeps the build result only in the build cache unless it is pushed to a registry.
+ # To generate signed build provenance attestations for containers,
+ # the subsequent steps require access to the image digest,
+ # which is in this case available only if the image is explicitly loaded:
+ # https://github.com/docker/build-push-action/issues/906#issuecomment-1674567311
+ load: ${{ github.event_name == 'pull_request' }}
+ # matrix.platform is required when load is true; otherwise, specifying platforms as a comma-separated string
+ # causes buildx to fail with: ERROR: docker exporter does not currently support exporting manifest lists
+ platforms: ${{ matrix.platform }}
# The tags generated in the metadata step include tags for both Docker Hub and GHCR image names,
# allowing the build and push action to build and push images to both registries.
tags: ${{ steps.meta.outputs.tags }}
@@ -97,15 +117,13 @@ jobs:
BUILDKIT_CONTEXT_KEEP_GIT_DIR=1
- name: Generate artifact attestation for GitHub Container Registry
- if: github.event_name != 'pull_request'
uses: actions/attest-build-provenance@v2
with:
subject-name: ghcr.io/${{ env.IMAGE_NAME}}
subject-digest: ${{ steps.build-and-push.outputs.digest }}
- push-to-registry: true
+ push-to-registry: ${{ github.event_name != 'pull_request' }}
- name: Generate artifact attestation for Docker Hub
- if: github.event_name != 'pull_request'
uses: actions/attest-build-provenance@v2
with:
# According to the documentation [^1],
@@ -114,4 +132,4 @@ jobs:
# [^1]: https://github.com/actions/attest-build-provenance?tab=readme-ov-file#container-image
subject-name: index.docker.io/${{ env.IMAGE_NAME}}
subject-digest: ${{ steps.build-and-push.outputs.digest }}
- push-to-registry: true
+ push-to-registry: ${{ github.event_name != 'pull_request' }} |
@oxzi I've added |
fad6fcf
to
1d0bf4b
Compare
Previously, we used https://github.com/Icinga/docker-icingadb to build and push container images because Icinga DB did not support features necessary for containerization, such as automatic schema import and configuration via environment variables. These were handled by a specific entrypoint in that repository. Now that these features are implemented directly in Icinga DB, the repository is no longer needed, and container images can be built and pushed directly from this repository.
The workflow using https://github.com/Icinga/docker-icingadb for building and publishing container images is now obsolete. We will replace it with a new workflow that builds and pushes container images directly from this repository.
This workflow builds and publishes container images directly from this repository. Here is a summary of its initial setup for reference: The Build and Publish Container Image workflow builds container images and pushes them to both GitHub Container Registry (GHCR) and Docker Hub. It sets up QEMU and Docker Buildx for cross-platform builds, and builds the container images using the Containerfile. Upon pushes to the main branch or when releases are published, it logs into GHCR and Docker Hub using credentials from GitHub secrets, tags and pushes the images to both registries, and generates and pushes signed build provenance attestations to each registry. The workflow also triggers for pull requests to the main branch, verifying only the image build.
Signed-off-by: Eric Lippmann <[email protected]>
…ctly See golang/go#51279 for reference. Signed-off-by: Eric Lippmann <[email protected]>
@Al2Klimov Since you have left some comments, I will wait for review before merging. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This PR introduces a Containerfile and replaces the workflow for building and pushing container images. Previously, we relied on https://github.com/Icinga/docker-icingadb due to missing features in Icinga DB, i.e. automatic schema import and configuration via environment variables. With these features now integrated into Icinga DB, the sibling repository is no longer necessary. The new workflow builds and pushes images directly from this repository to GitHub Container Registry (GHCR) and Docker Hub.