ci: publish Docker images to GHCR on release

[gyutaeb]

Summary

Extend the existing docker workflow to push images to GitHub Container Registry (ghcr.io/libbpf/bpftool) when a new tag is pushed or when changes are merged to main.

Behavior

Event	Action
Pull Request	Build and test locally (no push)
Push to main branch	Build multi-arch and push with main tag
Version tag (v1.0.0)	Build and push with version tag

Test

• Tested workflow on forked repository (github.com/gyutaeb/bpftool)

[Copilot]

Pull request overview

This PR extends the Docker workflow to publish bpftool container images to GitHub Container Registry (GHCR) when version tags are pushed or changes are merged to the main branch. It adds multi-architecture support (amd64/arm64) and build caching while preserving the existing PR testing workflow.

Changes:

• Add trigger for version tags and configure GHCR publishing on push events
• Add multi-architecture build support with Docker Buildx and QEMU
• Add build caching using GitHub Actions cache for improved build performance

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 4 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[gyutaeb]

@qmonnet
Thanks for review! I've added conditions to always build the test image for PRs, and to run multi-arch builds only on releases. I have also addressed all review comments.

[qmonnet]

Well I triggered a review from Copilot to see if it would catch anything interesting, but I haven't done my own review yet 😅

It looks good overall, but given that we don't reuse any step between the two cases (testing for PR vs. pushing a new image), why not make them separate jobs? It would avoid keeping the conditions for github.event_name being a PR at every step. (The linter is shared but it's small enough that we can duplicate it; we probably don't need it for pushing images by the way, especially because it runs after the image is built and pushed). What do you think?

[qmonnet]

Looks good, thank you!

Do I need to set up anything for ghcr.io before the workflow runs, or will it automatically create the new image repository on the first run?

[gyutaeb]

Looks good, thank you!

Do I need to set up anything for ghcr.io before the workflow runs, or will it automatically create the new image repository on the first run?

@qmonnet
No additional configuration is required! Merging this PR acts as a push to the main branch, so it will trigger a build for the bpftool:main image. Later, when a new version(e.g., v7.7.0) is released, the workflow will automatically build and push both the v7.7.0 and latest tags.

[qmonnet]

OK thank you let's merge it then 👍

[gyutaeb]

@qmonnet
Thank you! I will keep an eye on the workflow.
https://github.com/libbpf/bpftool/actions/runs/21025852702

[qmonnet]

Thanks!

I ticked the box to have packages show up on the home page of the repo.

One question, do you know what is the unknown/unknown arch image that is generated along with arm64 and amd64?

[gyutaeb]

@qmonnet
it looks like the GHCR package is set to private.

❯ docker pull ghcr.io/libbpf/bpftool:main
Error response from daemon: {"message":"unable to retrieve auth token: invalid username/password: unauthorized"}

• Solution:
  • Go to https://github.com/orgs/libbpf/packages
  • Click on the bpftool package
  • Click "Package settings" on the right side
  • In the "Danger Zone" section, select "Change package visibility" → Public

[gyutaeb]

Thanks!

I ticked the box to have packages show up on the home page of the repo.

One question, do you know what is the unknown/unknown arch image that is generated along with arm64 and amd64?

@qmonnet
When Docker Buildx builds multi-platform images, it automatically generates the attestations by default.
This attestation data has no OS/architecture information, so it appears as unknown/unknown.

It doesn't affect functionality, but if you want to remove it for a cleaner look, I can disable attestations in the workflow:

- name: Build and push Docker image
  uses: docker/build-push-action@v6
  with:
    # ... existing settings ...
    provenance: false
    sbom: false

[qmonnet]

it looks like the GHCR package is set to private.

Good catch, thank you. I don't have sufficient permissions in the libbpf organisation to make it public myself, let me ping someone who can.

it automatically generates the attestations by default.

Oh right, got it thanks! No problem, let's keep them.

[qmonnet]

Daniel changed the setting, it's visible now 🎉

[gyutaeb]

@qmonnet
Double-checked. Looks good!

❯ docker pull ghcr.io/libbpf/bpftool:main
0ec3d8645767: Already exists
08781c4af5f3: Download complete
a594ec760d2d: Download complete
951fe14e4e63: Download complete
ghcr.io/libbpf/bpftool:main