Publish v3 + v4 as platform variants

[polarathene]

TL;DR: Instead of cachyos/cachyos-v3:latest it'd be nicer to leverage the standard --platform linux/amd64/v3 multi-platform image support, given that's the only actual difference for these images.

---

I wasn't aware initially of the additional v3 and v4 variants published. The DockerHub page has very little context, similar to the README (effectively empty) and description of this repo (links to the x86-64 / v1 image only).

One would need to check this repo contents, or visit the CachyOS user DockerHub page to notice the v3/v4 images? (I didn't see any reference on the wiki either)

So I ended up following the wiki for optimized repos 😅 (I had tried to pull via --platform but that suggested no such images were published). Later found this repo, the approach can be simplified easily enough.

---

Perhaps it's a bit late now that you've already got images published for platforms as separate images at the registry, rather than as multi-platform images that leverage the same tag, but if you're open to changing from that, here's what that'd look like.

# Current:
docker pull cachyos/cachyos-v3

# Proposed:
docker pull --platform linux/amd64/v3 cachyos/cachyos

# NOTE: Variant would be v3 or v4 when that was pulled instead
$ docker inspect cachyos/cachyos | jq '.[] | {Os, Architecture, Variant}'
{
  "Os": "linux",
  "Architecture": "amd64",
  "Variant": null
}

This would enable building custom images that reference cachyos/cachyos with the desired platform variant without having to likewise adopt the same non-DRY approach as CachyOS has taken.

If a specific platform is needed, that can be done via FROM --platform=linux/amd64/v3 AS my-base-v3 for example. It'd otherwise use the default platform of the builder, or could be set at build time via --platform instead of relying on non-standard means.

Dockerfile

Adapted from current Dockerfile. Removing the need for separate Dockerfiles for v3 and v4 variants.

FROM archlinux:base-devel AS rootfs
RUN <<EOF
  pacman -Syu --noconfirm
  pacman -S --needed --noconfirm \
    pacman-contrib \
    git \
    openssh \
    sudo \
    curl 
EOF

COPY pacman.conf /etc/pacman.conf

# NOTE: These two files could instead remain as separate external files
COPY <<EOF /tmp/pacman-v3.conf
[cachyos-v3]
Include = /etc/pacman.d/cachyos-v3-mirrorlist
[cachyos-core-v3]
Include = /etc/pacman.d/cachyos-v3-mirrorlist
[cachyos-extra-v3]
Include = /etc/pacman.d/cachyos-v3-mirrorlist
EOF

COPY <<EOF /tmp/pacman-v4.conf
[cachyos-v4]
Include = /etc/pacman.d/cachyos-v4-mirrorlist
[cachyos-core-v4]
Include = /etc/pacman.d/cachyos-v4-mirrorlist
[cachyos-extra-v4]
Include = /etc/pacman.d/cachyos-v4-mirrorlist
EOF

RUN <<EOF
  # Prepend variant repos for selection priority:
  case "${TARGETVARIANT}" in
    ( 'v3' )  sed '/^\[cachyos\]/e cat /tmp/pacman-v3' /etc/pacman.conf ;;
    ( 'v4' )  sed '/^\[cachyos\]/e cat /tmp/pacman-v4' /etc/pacman.conf ;;
  esac
  rm /tmp/pacman-v3.conf /tmp/pacman-v4.conf

  curl https://raw.githubusercontent.com/CachyOS/CachyOS-PKGBUILDS/master/cachyos-mirrorlist/cachyos-mirrorlist -o /etc/pacman.d/cachyos-mirrorlist

  # Add own keyring for pacman to install signed packages:
  pacman-key --init
  pacman-key --recv-keys F3B607488DB35A47 --keyserver keyserver.ubuntu.com
  pacman-key --lsign-key F3B607488DB35A47

  pacman -Syu --noconfirm
  pacman -S --needed --noconfirm \
    cachyos-keyring \
    cachyos-mirrorlist \
    cachyos-v3-mirrorlist \
    cachyos-v4-mirrorlist \
    cachyos-hooks

  pacman -Syu --noconfirm
  rm -rf /var/lib/pacman/sync/*
  find /var/cache/pacman/ -type f -delete
EOF


FROM scratch
LABEL org.opencontainers.image.description="CachyOS - Arch-based distribution offering an easy installation, several customizations, and unique performance optimization."
COPY --from=rootfs / /
CMD ["/usr/bin/bash"]

The separate v3 and v4 Dockerfile shared the same final steps as the base Dockerfile. Similar to their pacman.conf variants when only a small snippet needed to be inserted.

This changes the way these variants are built. Instead of referring to a variant as a target or separate Dockerfile, you provide the platform:

# Before:
docker build --tag cachyos/cachyos .
docker build --tag cachyos/cachyos-v3 --file Dockerfile-v3

# After:
docker build --platform=linux/amd64/v3 --tag cachyos/cachyos .

Maintenance is simplified 😎

CI

Likewise, simplified to a single workflow:

name: CachyOS Docker Image

on:
  workflow_dispatch:
  schedule:
    # Build and publish daily at 13:41
    - cron: '41 13 * * *'
  push:
    branches:
      - 'master'

jobs:
  docker:
    runs-on: ubuntu-latest
    steps:
      - name: 'Checkout'
        uses: actions/checkout@v4

      - name: 'Set up QEMU'
        uses: docker/setup-qemu-action@v3
        with:
          platforms: amd64

      - name: 'Set up Docker Buildx'
        uses: docker/setup-buildx-action@v3

      - name: 'Login to DockerHub'
        uses: docker/login-action@v3
        with:
          registry: docker.io
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      - name: 'Login to GitHub Container Registry'
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: 'Build and publish images'
        uses: docker/build-push-action@v6
        with:
          context: .
          platforms: linux/amd64,linux/amd64/v3,linux/amd64/v4
          push: true
          tags: cachyos/cachyos:latest

That should publish a multi-platform image, main changes to workflow are:

• docker/setup-qemu-action explicitly loads the only platform being published (_technically there may be no benefit to this step if there's no ARM64 images being built? (Unless the AMD64 images were to be built by the CI from a ARM64 host)
• docker/login-action added additional registry to publish (GHCR).
• docker/build-push-action adds platforms to build the variants, removing the need for their separate workflow copies. They would now all be built under the same tag published to the registry and available via standard --platform arg.
• YAML format / style (list + cron comment).

Potentially related: #4