Closed ocervell closed 1 year ago
What is the objective/value here? Being able to pull images from GitHub's own registry in GitHub Actions workflows?
Yes, for instance, or have a public image hosted on ghcr.io in case GCR is for some reason unavailable / down (since it's on a test org project ..)
Sounds good. I think the best option is to add this feature to cloudbuild.yaml
so every workflow (build
and deploy
mainly) automatically inherits it when they run make cloudbuild
. We could use GitHub Actions to stay within GitHub but that would make the code less maintainable in my opinion. Let's build once in a single place, and push to many registries as needed.
The Container Registry documentation is here, with instructions on how to authenticate and how to push. From Cloud Build, we can probably authenticate by forwarding the workflow's ${{ secrets.GITHUB_TOKEN }}
(compared to a Personal Access Token) as the image will be pushed to the same repository as the workflow itself.
Here is a sample GitHub Actions workflow responsible for building and publishing a package to the GitHub Container Registry: https://docs.github.com/en/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions#publishing-a-package-using-an-action
Let's use the sample GitHub Actions workflow above as we are in a bit of a hurry. I had to remove public access to the GCS bucket hosting the Docker images of the Container Registry after a huge spike in egress costs in October. Some users like Adeo have their own image in a private registry, so they are not impacted. I granted the right permissions to other users like Decathlon, so they are not impacted either. This being said, other users (new and existing) might be impacted so we need an alternative to gcr.io
. I successfully tested the workflow above in another repository. I just had to adapt it to semantic versioning (semver).
Currently we deploy to GCR only