2c6c7fdb23
* Adds capability of switching to Github Container Registry Currently we are using GitHub Packages to cache images for the build. GitHub Packages are "legacy" storage of binary artifacts for GitHub and as of September 2020 they introduced Github Container Registry as more stable, easier to manage replacement for container storage. It includes complete self-management of the images including permission management, public access, retention management and many more. More about it here: https://github.blog/2020-09-01-introducing-github-container-registry/ Recently we started to experience unstable behaviour of the Github Packages ('unknown blob' and manifest v1 vs. v2 when pushing images to it. So together with ASF we proposed to enable Github Container Registry and it happened as of January 2020. More about it in https://issues.apache.org/jira/browse/INFRA-20959 We are currently in the testing phase, especially when it comes to management of permissions - the model of permission mangement is not the same for Container Registry as it was for GitHub Packages (it was per-repository in GitHub Packages, but it is organization-wide in the Container Registry. This PR introduces an option to use GitHub Container Registry rather than GitHub Packages. It is implemented in both - CI level and Breeze level allowing to seamlessly switch between those two solutions: In Breeze (which we use to test pushing/pulling the images) --github-registry option was added with `ghcr.io` (Github Container Registry) or `docker.pkg.github.com` (GitHub Packages). In CI the same can be achieved by setting GITHUB_REGISTRY value (same values possible as for --github-registry Breeze parameter) * fixup! Adds capability of switching to Github Container Registry |
||
---|---|---|
.. | ||
ISSUE_TEMPLATE | ||
actions | ||
workflows | ||
PULL_REQUEST_TEMPLATE.md | ||
SECURITY.rst | ||
boring-cyborg.yml | ||
mergeable.yml | ||
stale.yml |