publish images: amd64/arm64 images containing cli only #2770
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -25,8 +25,12 @@ jobs: | |
| strategy: | ||
| matrix: | ||
| include: | ||
| - name: cilium-cli-ci | ||
| dockerfile: ./Dockerfile | ||
| platforms: linux/amd64 | ||
| - name: cilium-cli | ||
| dockerfile: ./Dockerfile | ||
| platforms: linux/amd64,linux/arm64 | ||
| steps: | ||
| - name: Set up Docker Buildx | ||
| uses: docker/setup-buildx-action@988b5a0280414f521da01fcc63a27aeeb4b104db # v3.6.1 | ||
|
|
@@ -63,18 +67,20 @@ jobs: | |
| context: . | ||
| file: ${{ matrix.dockerfile }} | ||
| push: true | ||
| platforms: ${{ matrix.platforms }} | ||
| build-args: | | ||
| FINAL_CONTAINER=${{ matrix.name }} | ||
| tags: | | ||
| quay.io/${{ github.repository_owner }}/${{ matrix.name }}:latest | ||
| quay.io/${{ github.repository_owner }}/${{ matrix.name }}:${{ steps.tag.outputs.tag }} | ||
|
Comment on lines
-68
to
+75
There was a problem hiding this comment. Reviewing on behalf of @cilium/security: We keep the CI workflows, builds, environment and secrets entirely separate from the production versions to reduce the risk to supply chain security. I think it probably makes sense to split this overall effort into two steps:
@michi-covalent / @tklauser then the other aspect is how we're validating these workflow changes. I believe that deliberately these changes to the workflows would not be tested from the fork, because that would mean that arbitrary contributors could hijack the workflows to do what they want. So we probably need to collaborate a little more closely to validate any changes like this separately. That might look like enabling this on a third party github repo and validating there, or at your discretion merging the commits and keeping an eye on them for any potential breakage in the tree. There was a problem hiding this comment.
@michi-covalent if we only need to publish untrusted CI versions of the workflows, something like this works. However, if we intend to publish trusted production builds that we can validate are definitely based only on input from vetted code merged into the tree, then I think it's essential to keep those in a dedicated different repository. With a different repository we can enforce stricter constraints around how code flows into that repository, access to secrets, maintainer approval of individual builds. There was a problem hiding this comment.
cilium-cli/.github/workflows/images.yaml Lines 27 to 33 in 8aec284 Also adding the new -ci suffixless version, which could be a seperate PR however the Dockerfile changes are already merged There was a problem hiding this comment. @joestringer cilium-cli/.github/workflows/images.yaml Lines 61 to 75 in 8aec284 which only builds latest and the tagged release when main/tag is pushed There was a problem hiding this comment. The Typically the way we handle this in cilium/cilium is that there is an entirely different set of secrets for official builds vs. CI, then there is a dedicated GitHub environment for the official builds that applies strict limits on how builds can be created (for example, requiring maintainer approval), and finally there are different workflows for the different builds with different triggers. |
||
|
|
||
| - name: CI Image Releases digests | ||
| if: ${{ github.event_name != 'pull_request_target' }} | ||
| shell: bash | ||
| run: | | ||
| mkdir -p image-digest/ | ||
| echo "quay.io/${{ github.repository_owner }}/${{ matrix.name }}:latest@${{ steps.docker_build_ci_main.outputs.digest }}" > image-digest/${{ matrix.name }}.txt | ||
| echo "quay.io/${{ github.repository_owner }}/${{ matrix.name }}:${{ steps.tag.outputs.tag }}@${{ steps.docker_build_ci_main.outputs.digest }}" >> image-digest/${{ matrix.name }}.txt | ||
|
|
||
| # PR updates | ||
| - name: CI Build ${{ matrix.name }} | ||
|
|
@@ -85,16 +91,18 @@ jobs: | |
| context: . | ||
| file: ${{ matrix.dockerfile }} | ||
| push: true | ||
| platforms: ${{ matrix.platforms }} | ||
| build-args: | | ||
| FINAL_CONTAINER=${{ matrix.name }} | ||
| tags: | | ||
| quay.io/${{ github.repository_owner }}/${{ matrix.name }}:${{ steps.tag.outputs.tag }} | ||
|
|
||
| - name: CI Image Releases digests | ||
| if: ${{ github.event_name == 'pull_request_target' }} | ||
| shell: bash | ||
| run: | | ||
| mkdir -p image-digest/ | ||
| echo "quay.io/${{ github.repository_owner }}/${{ matrix.name }}:${{ steps.tag.outputs.tag }}@${{ steps.docker_build_ci_pr.outputs.digest }}" > image-digest/${{ matrix.name }}.txt | ||
|
|
||
| # Upload artifact digests | ||
| - name: Upload artifact digests | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -3,32 +3,42 @@ | |
| # Copyright Authors of Cilium | ||
| # SPDX-License-Identifier: Apache-2.0 | ||
|
|
||
| # FINAL_CONTAINER specifies the source for the output | ||
| # cilium-cli-ci (default) is based on ubuntu with cloud CLIs | ||
| # cilium-cli is from scratch only including cilium binaries | ||
| ARG FINAL_CONTAINER="cilium-cli-ci" | ||
|
|
||
| FROM docker.io/library/golang:1.23.1-alpine3.19@sha256:e0ea2a119ae0939a6d449ea18b2b1ba30b44986ec48dbb88f3a93371b4bf8750 AS builder | ||
| WORKDIR /go/src/github.com/cilium/cilium-cli | ||
| RUN apk add --no-cache git make ca-certificates | ||
| COPY . . | ||
| RUN make | ||
|
|
||
| FROM scratch AS cilium-cli | ||
| COPY --from=builder /go/src/github.com/cilium/cilium-cli/cilium /usr/local/bin/cilium | ||
|
|
||
| FROM ubuntu:24.04@sha256:56a8952801afd93876eea675cae9ab861bf8d2e6a4f978e4b0237ce94e1c3b49 AS cilium-cli-ci | ||
| COPY --from=builder /go/src/github.com/cilium/cilium-cli/cilium /usr/local/bin/cilium | ||
|
|
||
| # Install cloud CLIs. Based on these instructions: | ||
| # - https://cloud.google.com/sdk/docs/install#deb | ||
| # - https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html | ||
| # - https://learn.microsoft.com/en-us/cli/azure/install-azure-cli-linux?pivots=apt#install-azure-cli | ||
| RUN apt-get update -y \ | ||
| && apt-get install -y curl gnupg unzip \ | ||
| && curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | gpg --dearmor -o /usr/share/keyrings/cloud.google.gpg \ | ||
| && curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - \ | ||
| && echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | tee -a /etc/apt/sources.list.d/google-cloud-sdk.list \ | ||
| && apt-get update -y \ | ||
| && apt-get install -y google-cloud-cli google-cloud-sdk-gke-gcloud-auth-plugin kubectl \ | ||
| && curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" \ | ||
| && unzip awscliv2.zip \ | ||
| && ./aws/install \ | ||
| && rm -r ./aws awscliv2.zip \ | ||
| && curl -sL https://aka.ms/InstallAzureCLIDeb | bash | ||
|
|
||
| # Select the layer to provide the final container image from | ||
| FROM ${FINAL_CONTAINER} | ||
| LABEL maintainer="[email protected]" | ||
| WORKDIR /root/app | ||
| ENTRYPOINT [] | ||
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.
As for the SBOM question from the community meeting: I think that it's not so important for CI builds (see also cilium/cilium#35116), though having SBOM on CI builds can help us to find out if the SBOM steps in the workflow are working or not before we go to do a release.
For releases for CLI, I think SBOM can be valuable and should be relatively straightforward (something like https://github.com/cilium/cilium/blob/475310f713fb25897b1b939668c73db7da359d08/.github/workflows/build-images-releases.yaml#L121-L134), but let's get the repos up and running first and worry about SBOM after.