Skip to content
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

feat: add zizmor Docker image #319

Closed
wants to merge 7 commits into from
Closed
Show file tree
Hide file tree
Changes from 6 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions .github/dependabot.yml
Original file line number Diff line number Diff line change
Expand Up @@ -17,3 +17,12 @@ updates:
github-actions:
patterns:
- "*"

- package-ecosystem: docker
directory: "/"
schedule:
interval: "weekly"
groups:
docker:
patterns:
- "*"
47 changes: 47 additions & 0 deletions .github/workflows/pypi.yml
Original file line number Diff line number Diff line change
Expand Up @@ -176,3 +176,50 @@ jobs:
with:
command: upload
args: --non-interactive --skip-existing wheels-*/*

docker-build:
name: Build and publish Docker image
runs-on: ubuntu-latest
env:
ZIZMOR_IMAGE: ghcr.io/woodruffw/zizmor
environment:
name: docker
if: ${{ startsWith(github.ref, 'refs/tags/') || github.event_name == 'workflow_dispatch' }}
# Only run if the release job was successfully completed
needs: [release]
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There might be a bit of a race condition with this, sadly: PyPI's propagation can take a few minutes IME, so running immediately after a release might fail due to the index not listing the release yet.

I think there are two (easy-ish) options here:

  1. Add some kind of blocking "wait for PyPI" job so that the flow goes release -> wait-for-pypi -> docker-build instead
  2. Move this to a separate docker-publish.yml or similar that can be triggered separately, e.g. by a workflow_dispatch with a tag: input

I'd be OK with either of these but a slight preference for (2), especially since we can give it a cron trigger that'll do the update automatically πŸ™‚

Copy link
Contributor Author

@trallard trallard Feb 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was initially going for 2-ish, but then I realized the trigger would need to be other than a release tag so that this did not end up running before the PyPI release was ready, so I moved this inside the PyPI workflow, though I completely forgot about the potential delays on the PyPI side.

Let me move this out into a separate workflow again, as in 2) and we can sort out the trigger event (cron or something else).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another alternative could be using the built wheels (already uploaded to the artefacts) to install zizmor (thus avoiding any potential delays on the PyPI side of things) so all the workflows would trigger from the same release tag event.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That could work, although in that case we'd need to reimplement the wheel/tag matching, right? I think a separate workflow + trigger is good for now πŸ™‚

permissions:
contents: read
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4
with:
persist-credentials: false
- name: Set up QEMU
uses: docker/setup-qemu-action@53851d14592bedcffcf25ea515637cff71ef929a # v3
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@6524bf65af31da8d45b59e8c27de4bd072b392f5 # v3
- name: Extract Docker metadata
id: docker-metadata
uses: docker/metadata-action@369eb591f429131d6889c46b94e711f089e6ca96 # v5
with:
images: "${{ env.ZIZMOR_IMAGE }}"
tags: |
# use the release tag for the image tag too
type=ref, event=tag
- name: Login to GHRC
uses: docker/login-action@9780b0c442fbb1117ed29e0efdff1e18412f7567 # v6
if: github.repository_owner == 'woodruffw'
with:
registry: ghcr.io
username: "${{ github.repository_owner }}"
password: "${{ secrets.GITHUB_TOKEN }}"
- name: Build and push Docker image
uses: docker/build-push-action@ca877d9245402d1537745e0e356eab47c3520991 # v6
with:
context: .
push: true
tags: ${{ steps.docker-metadata.outputs.tags }}
build-args: |
ZIZMOR_VERSION=${{ github.ref_name }}
platforms: linux/amd64,linux/arm64
# Build provenance attestations
provenance: true
35 changes: 35 additions & 0 deletions Dockerfile
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
FROM python:3.12-slim-bookworm AS build

LABEL org.opencontainers.image.source=https://github.com/woodruffw/zizmor

# Zizmor version to install (set as an argument to pair with zizmor releases)
ARG ZIZMOR_VERSION

ENV PYTHONUNBUFFERED=1 \
PIP_NO_CACHE_DIR=1 \
PIP_DISABLE_PIP_VERSION_CHECK=1

# Add Rust to PATH
ENV PATH="/root/.cargo/bin:${PATH}"
ENV PATH="/root/.local/bin:${PATH}"

RUN set -eux && \
apt-get update && \
apt-get clean && \
rm -rf /var/lib/apt/lists/*

RUN pip install uv && \
uv tool install zizmor=="${ZIZMOR_VERSION}" && \
which zizmor

# ------------------------------------------------------------------------------
# Runtime image
# ------------------------------------------------------------------------------

FROM python:3.12-slim-bookworm

# Copy necessary files from build stage
COPY --from=build /root/.local/bin/zizmor /root/.local/bin/zizmor

# Set the entrypoint to zizmor
ENTRYPOINT ["/root/.local/bin/zizmor"]