MON-196408 [CI] Use ghcr.io (github containers) to store fat containe…

[Tpo76]

Context

GitHub Actions cache limits are hit fast due to very large Docker images being saved as cache artifacts, leading to broken runs and frustration for anyone using the pipelines.

Changes

Replaced the docker save → cache/save / cache/restore → docker load pattern with a direct push/pull to ghcr.io for the following workflows:

perl-cpan-libraries.yml

• get-packaging-images job: pull from Harbor → tag → push to ghcr.io
• package-rpm / package-deb jobs: pull directly from ghcr.io (no cache restore, no docker load)

plugins-robot-tests.yml

• Renamed test-image-to-cache → push-test-image-to-ghcr
• Same pattern: pull from Harbor → tag → push to ghcr.io
• robot-test job: pull directly from ghcr.io

Image naming

ghcr.io/${{ github.repository }}/<image>:<sha>-<run_id> — same uniqueness as the previous cache key, maintaining run isolation.

Auth

Uses GITHUB_TOKEN with packages: write — no extra secret or PAT needed, consistent with MON-196690.

Follow-up

Ephemeral images tagged with sha-run_id will accumulate in ghcr.io. A cleanup mechanism (similar to cleanup-ghcr-registry.yml in delivery-tooling) should be added as a
follow-up.

Related

• MON-196408
• MON-196690 (phase 1 — same approach validated for centreon/centreon-collect, centreon/centreon, centreon/centreon-modules)

Summary by Aikido

Security Issues: 0	Quality Issues: 0	Resolved Issues: 0

⚡ Enhancements

• Replaced cache-based image storage with ghcr.io push/pull across workflows
• Added Docker login to ghcr.io using GITHUB_TOKEN for registry access
• Tagged ephemeral images with sha-run_id to preserve run-specific uniqueness
• Added packages: write permissions so workflows could push images to ghcr

🔧 Refactors

• Renamed test-image-to-cache job to push-test-image-to-ghcr and simplified logic

^{More info}