Today our test containers (rucio/test-fts, rucio/test-xrootd, rucio/test-ssh, rucio/test-webdav) are mostly tagged by containers/Rucio release or latest. For LTS branches in rucio/rucio, this makes the dev/test environment non‑reproducible and tightly couples the container tags to Rucio versions instead of the underlying services they wrap.
I’d like to introduce service‑versioned tags for these images (in addition to the existing release tags), e.g.:
rucio/test-fts:fts3-prod-<fts_server_version>-el9
rucio/test-xrootd:xrootd-<xrootd_version>-el9
rucio/test-ssh:ssh-<ssh-version>-almalinux9
rucio/test-webdav:webdav-<webdav-version>-almalinux9
Each image would:
- Pin the relevant service RPMs via Dockerfile build args.
- Be built by a small
workflow_dispatch GitHub Action (one per test image or shared pattern).
- Skip rebuilding if the tag already exists on Docker Hub.
The existing .github/workflows/docker-auto-build.yml would stay as‑is and continue to publish images tagged by containers repo releases. LTS branches in rucio/rucio will then explicitly pin to these service‑versioned tags instead of latest.
Related Issue on main repo: rucio/rucio#8419
Today our test containers (
rucio/test-fts,rucio/test-xrootd,rucio/test-ssh,rucio/test-webdav) are mostly tagged by containers/Rucio release or latest. For LTS branches in rucio/rucio, this makes the dev/test environment non‑reproducible and tightly couples the container tags to Rucio versions instead of the underlying services they wrap.I’d like to introduce service‑versioned tags for these images (in addition to the existing release tags), e.g.:
Each image would:
workflow_dispatchGitHub Action (one per test image or shared pattern).The existing
.github/workflows/docker-auto-build.ymlwould stay as‑is and continue to publish images tagged by containers repo releases. LTS branches inrucio/ruciowill then explicitly pin to these service‑versioned tags instead of latest.Related Issue on main repo: rucio/rucio#8419