Skip to content

Stage OCI container images through GitHub Actions (GHA) to GitHub Container Registry (GHCR) / Provide OCI images for ARM64#69

Open
amotl wants to merge 3 commits into
owntracks:masterfrom
daq-tools:buildx-gha
Open

Stage OCI container images through GitHub Actions (GHA) to GitHub Container Registry (GHCR) / Provide OCI images for ARM64#69
amotl wants to merge 3 commits into
owntracks:masterfrom
daq-tools:buildx-gha

Conversation

@amotl
Copy link
Copy Markdown

@amotl amotl commented May 20, 2023

Even if GH-66 is not strictly needed, as Docker Inc. will continue their FOSS offering, this patch would set the stage to do so without much ado.

Its main purpose, however, is to resolve GH-68, and start providing OCI images for ARMv7 and ARM64, other than AMD64. We are using this recipe on a few other repositories, including mqttwarn, and it works well.

As a benefit in comparison to the previous build system, this recipe will provide image variants for latest, nightly, and pr-XXX builds.

Comment thread .github/workflows/oci.yml
Comment on lines +92 to +103
- name: Log in to GHCR
uses: docker/login-action@v2
with:
registry: ghcr.io
username: ${{ github.repository_owner }}
password: ${{ github.token }}

#- name: Log in to Docker Hub
# uses: docker/login-action@v2
# with:
# username: ${{ secrets.DOCKER_USERNAME }}
# password: ${{ secrets.DOCKER_PASSWORD }}
Copy link
Copy Markdown
Author

@amotl amotl May 20, 2023

Choose a reason for hiding this comment

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

You probably want to swap that after populating the secrets settings right, in order to keep publishing to the known location at Docker Hub.

Currently, the workflow publishes to GitHub Container Registry (GHCR),
but it can be diverted to Docker Hub any time.
@amotl
Copy link
Copy Markdown
Author

amotl commented May 20, 2023

Hm. I see. What's special here is that it's a separate repository, and connects to the release of the recorder program using the RECORDER_VERSION definition within Dockerfile. Because of that, this recipe will not be able to deliver its full feature set.

Would you fancy a re-thinking of this architecture, by folding the contents of this repository into a oci-packaging directory of the recorder repository 1, where actual development is happening? In this manner, all pieces would fit together well, and would not need any "external" release steps any longer.

Footnotes

  1. Similar to the debian directory there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

docker linux/arm64 build

2 participants