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

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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

amotl
Copy link

@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 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
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
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
1 participant