ci-workflows

Shared GitHub Actions for the Pubky organisation. Changing anything here changes the builds of every consuming repository, so read the policy below before opening a PR.

Actions

Action	Purpose
docker/build_and_push	Build a multi-arch image and push it to GCP Artifact Registry or Docker Hub
docker/registry_login	Log in to either registry, chosen from the registry hostname
docker/check_if_image_exists	Check whether a tag already exists for a given architecture
docker/get_head_commit_hash	Deprecated. build_and_push resolves the hash itself

- uses: pubky/ci-workflows/.github/actions/docker/registry_login@main
  with:
    registry: europe-west6-docker.pkg.dev/infra-464608/synonym-private-repo
    gcp_service_account_key: ${{ secrets.GCR_JSON_KEY }}

- uses: pubky/ci-workflows/.github/actions/docker/build_and_push@main
  with:
    registry: europe-west6-docker.pkg.dev/infra-464608/synonym-private-repo
    image: my-service
    context: .

cache_from and cache_to are passed straight to docker/build-push-action and accept newline-separated entries. An unset input means no cache — the action emits no --cache-from / --cache-to flag at all, exactly as docker/build-push-action behaves on its own. Caching is opt-in:

cache_from: |
  type=gha,scope=amd64
  type=gha,scope=arm64
cache_to: type=gha,mode=max

Exporting a cache is slow and is only worth it when a later build reads it. A release build usually has no such reader, so leaving cache_to unset is often the right choice.

Reusable workflows

context7-sync.yml refreshes the calling repository's library in Context7. The library must already be registered in Context7. Add this workflow to each consuming repository:

name: Sync to Context7

on:
  push:
    tags: ['v*']
  workflow_dispatch:

permissions: {}

jobs:
  refresh-context7:
    uses: pubky/ci-workflows/.github/workflows/context7-sync.yml@main
    secrets:
      CONTEXT7_API_KEY: ${{ secrets.CONTEXT7_API_KEY }}

Set CONTEXT7_API_KEY as a secret in the calling repository, or as an organization secret with access granted to that repository. The caller controls when the workflow runs; the shared workflow uses github.repository to select its Context7 library.

Policy

Third-party actions are pinned to a commit SHA, with the version in a trailing comment:

uses: docker/login-action@c94ce9fb468520275223c153574b00df6fe4bcc9 # v3

A tag can be moved by its owner; a SHA cannot. The comment is not decoration — Dependabot reads it to work out which version a pin corresponds to, and raises bump PRs weekly with a 7-day cooldown so a freshly published release is never proposed the moment it lands.

No action here may reference another action in this repository. Doing so reintroduces a floating @main that a consumer cannot pin past.

zizmor runs on every pull request and blocks the merge. Results are uploaded to the repository's Security tab as SARIF. To reproduce locally:

docker run --rm -e GH_TOKEN="$(gh auth token)" -v "$PWD:/src:ro" -w /src \
  ghcr.io/zizmorcore/zizmor:1.30.0 .

Versioning

Releases are tagged from v1.0.0. Consumers currently reference @main; the tags exist so that a later migration to pinned references has real version history to pin against.