-
Notifications
You must be signed in to change notification settings - Fork 229
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
ci: build and push Docker image based on Chainguard base image #4005
Conversation
Signed-off-by: Victor Martinez <VictorMartinezRubio@gmail.com>
I'll wait until you've updated this PR after 3998 is merged before doing a final review. |
I'm not sure of the value of using a matrix for the two Dockerfiles. I think it adds more complexity than it saves in a little duplication. |
Feel free to push back on that if you are using the same pattern in other repos. |
…es-wolfi * upstream/main: ci: use docker/metadata-action to gather tags/labels (elastic#3998) chore(deps): bump @opentelemetry/exporter-prometheus (elastic#4016) chore(deps): bump @opentelemetry/sdk-metrics to 1.24.1 in test fixtures (elastic#4015) chore(deps): bump @opentelemetry/sdk-metrics from 1.24.0 to 1.24.1 (elastic#4014) chore(deps-dev): bump azure-functions-core-tools (elastic#4017) chore(deps-dev): bump undici from 6.15.0 to 6.16.1 (elastic#4013) chore(deps-dev): bump fastify from 4.26.2 to 4.27.0 (elastic#4012) chore(deps): bump pino from 8.17.1 to 8.21.0 (elastic#4011) chore(deps): bump @opentelemetry/core from 1.24.0 to 1.24.1 (elastic#4010) chore(deps-dev): bump mongodb from 6.6.0 to 6.6.1 (elastic#4009) chore(deps-dev): bump eslint-plugin-n in the eslint group (elastic#4008)
Do you prefer something like this? diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
index 942b6e4e..76ddaa37 100644
--- a/.github/workflows/release.yml
+++ b/.github/workflows/release.yml
@@ -62,6 +62,7 @@ jobs:
uses: docker/build-push-action@2cdde995de11925a030ce8070c3d77a52ffcf1c0 # v5.3.0
with:
context: .
+ file: 'Dockerfile'
push: true
tags: ${{ steps.docker-meta.outputs.tags }}
labels: ${{ steps.docker-meta.outputs.labels }}
@@ -75,6 +76,39 @@ jobs:
subject-digest: ${{ steps.docker-push.outputs.digest }}
push-to-registry: true
+ - name: Extract metadata (tags, labels) (wolfi)
+ id: docker-meta-wolfi
+ uses: docker/metadata-action@8e5442c4ef9f78752691e2d8f8d19755c6f78e81 # v5.5.1
+ with:
+ images: ${{ env.DOCKER_IMAGE_NAME }}
+ flavor: |
+ latest=auto
+ suffix=-wolfi
+ tags: |
+ # "1.2.3" and "latest" Docker tags on push of git tag "v1.2.3"
+ type=semver,pattern={{version}}
+ # "edge" Docker tag on git push to default branch
+ type=edge
+
+ - name: Build and Push Docker Image (wolfi)
+ id: docker-push-wolfi
+ uses: docker/build-push-action@2cdde995de11925a030ce8070c3d77a52ffcf1c0 # v5.3.0
+ with:
+ context: .
+ file: 'Dockerfile.wolfi'
+ push: true
+ tags: ${{ steps.docker-meta-wolfi.outputs.tags }}
+ labels: ${{ steps.docker-meta-wolfi.outputs.labels }}
+ build-args: |
+ AGENT_DIR=/build/dist/nodejs
+
+ - name: Attest Docker image (wolfi)
+ uses: github-early-access/generate-build-provenance@main
+ with:
+ subject-name: "${{ env.DOCKER_IMAGE_NAME }}"
+ subject-digest: ${{ steps.docker-push-wolfi.outputs.digest }}
+ push-to-registry: true
+
- name: Read AWS vault secrets
uses: hashicorp/vault-action@v3.0.0
with:
diff --git a/Dockerfile.wolfi b/Dockerfile.wolfi
new file mode 100644
index 00000000..f0361904
--- /dev/null
+++ b/Dockerfile.wolfi
@@ -0,0 +1,3 @@
+FROM docker.elastic.co/wolfi/chainguard-base@sha256:9f940409f96296ef56140bcc4665c204dd499af4c32c96cc00e792558097c3f1
+ARG AGENT_DIR
+COPY ${AGENT_DIR} /opt/nodejs Rather than the matrix approach? |
Yes. Personally I think that looks clearer. Are you already doing a matrix-based workflow for other APM repos? |
I did it for the APM Agent Python -> elastic/apm-agent-python#2036 But it's not merged yet and we can change it if needed. Each agent has its own idiosyncrasy., I'm happy to change it if makes thing easier to read. I'll apply the new changes now in this PR |
This had been done for other uses in this workflow in elastic#4025, and then this additional usage was added a bit later in elastic#4005.
What does this pull request do?
Release two flavours of Docker images:
Please note that we are going to preserve the current
Dockerfile
, so that users will still be able to build their own custom images based onAlpine
: this is needed becausedocker.elastic.co/wolfi/chainguard-base
is not a public base image, so docker build would fail for unauthenticated users.Implementation details
I refactored the release workflow to have three different jobs that run sequentially:
Dockerfile
andDockerfile.wolfi
Then, I created the
Dockerfile.wolfi
- the naming convention we agreed upon.Tests
I created a feature branch
test-wolfi
:Then I was able to test the release workflow without pushing any changes in production but generating docker images with the prefix
test-
and suffix if-wolfi
.See https://github.com/elastic/apm-agent-nodejs/actions/runs/9082550246
Docker images
The ones we usually release
See this line
Wolfi docker images
See this line
docker pull docker.elastic.co/observability/apm-agent-nodejs:test-latest-wolfi
Issues
Similar to elastic/apm-agent-python#2036
Requires #3998
Checklist