Add weekly CI container build for pre-installed test dependencies

[adrianreber]

Currently the coverage.yml and tests.yml workflows use fedora:latest as their container image and install all required packages (golang, bats, criu, ShellCheck, etc.) from scratch on every single CI run. This means
every push and every pull request spends time running dnf install before any actual test work begins, adding unnecessary latency and putting load on Fedora mirrors.

This PR introduces a pre-built CI container image that has all required ackages already installed. The image is built once a week and pushed to the GitHub Container Registry (ghcr.io), so that the test and coverage workflows can pull it directly and skip the package installation step entirely.

The changes are split into two commits intentionally. This first commit adds the container infrastructure — the Containerfile and the build and cleanup workflows — so that the container image is created and available
in the registry before the test workflows are updated to reference it. The second commit, which switches coverage.yml and tests.yml to use the pre-built image, will be submitted separately once the image exists.

[github-actions]

Test Results

86 tests  ±0   86 ✅ ±0   3s ⏱️ ±0s
 1 suites ±0    0 💤 ±0 
 1 files   ±0    0 ❌ ±0 

Results for commit fe27bc3. ± Comparison against base commit a9e0ef7.

♻️ This comment has been updated with latest results.

[rst0git]

I tried something similar in the past with the CRIU project, as I thought that using pre-built CI container images would reduce the amount of time needed to run the tests, but it doesn't seem to make a difference.

@adrianreber The checkpointctl tests run in CI for about 1 minute, with and without this change. Do we really want introduce a pre-built CI container image?

[adrianreber]

I tried something similar in the past with the CRIU project, as I thought that using pre-built CI container images would reduce the amount of time needed to run the tests, but it doesn't seem to make a difference.

@adrianreber The checkpointctl tests run in CI for about 1 minute, with and without this change. Do we really want introduce a pre-built CI container image?

This is a valid question. Looking at the CI times we are spending the biggest chunk in installing tools (only 24 seconds). So it reduce the runtime by a third maybe, but it is not really much.

Another (and main) motivation was to unify the different GitHub actions scripts. Currently we are installing different tools in different steps and just installing it once would remove a couple of sections from the yaml files. I think having just one place defining the CI package list would be nice. Maybe we are less dependent on external mirrors. Not sure.

Maybe for the short running tests it makes even more sense? If tests are running for 20 minutes it doesn't change anything.

[rst0git]

@adrianreber Have you considered using the Containerfile‎ directly in the GitHub Actions?
(that way we don't need to build and publish images every week)

• https://docs.github.com/en/actions/reference/workflows-and-actions/dockerfile-support
• https://docs.github.com/en/actions/tutorials/use-containerized-services/create-a-docker-container-action

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.98%. Comparing base (a9e0ef7) to head (fe27bc3).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #215   +/-   ##
=======================================
  Coverage   79.98%   79.98%           
=======================================
  Files          16       16           
  Lines        1759     1759           
=======================================
  Hits         1407     1407           
  Misses        263      263           
  Partials       89       89           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[adrianreber]

@adrianreber Have you considered using the Containerfile‎ directly in the GitHub Actions? (that way we don't need to build and publish images every week)

* https://docs.github.com/en/actions/reference/workflows-and-actions/dockerfile-support

* https://docs.github.com/en/actions/tutorials/use-containerized-services/create-a-docker-container-action

I read the documentation but I do not get it. What are you proposing?

[rst0git]

GitHub actions can use a Dockerfile (or Containerfile) instead of container image:

runs:
  using: 'docker'
  image: 'Dockerfile'

GitHub will build an image from your Dockerfile, and run commands in a new container using this image.

https://docs.github.com/en/actions/tutorials/use-containerized-services/create-a-docker-container-action#creating-an-action-metadata-file

[adrianreber]

GitHub actions can use a Dockerfile (or Containerfile) instead of container image:

I do not see this as useful here.