Publish v3 + v4 as platform variants
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 38/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- docker, dockerfile, github-actions
- Domain
- ci-cd, devops, infrastructure
Research direction
Read the current Dockerfile, the separate v3 and v4 Dockerfiles, their pacman.conf variants, and the copied CI workflow files; also review related pull request #4. Check how the existing images are built and published before assessing the proposed platform-based workflow. Done means the v3 and v4 variants are published under one image tag and remain selectable through Docker's standard --platform option.
Written by the indexing model from the issue text.
Description
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-actionexplicitly 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-actionadded additional registry to publish (GHCR).docker/build-push-actionaddsplatformsto 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--platformarg.- YAML format / style (list + cron comment).
Potentially related: https://github.com/CachyOS/docker/pull/4
- Dominant language
- Dockerfile
- Stars
- 32
- Forks
- 6
- PR merge metrics
- No merged PRs in 30d
Getting set up
We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from CachyOS/docker
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
-
arm64 docker imagesOpen
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
siderolabs/terraform-provider-talos#414 ·
Maintainers usually reply within 1 day
-
agent/quality hive/hosted-available-lke648397-260827-5n31 quality testing
Difficulty 2/5 1-3 hours Newbie friendliness 91/100
Maintainers usually reply within 1 day
-
Mend: dependency security vulnerability
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
area/helm kind/bug priority/backlog triage/accepted
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
lexfrei/cloudflare-tunnel-gateway-controller#835 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
JPHutchins/code-review#262 ·
Maintainers usually reply within 1 day