Since tentacle, the preferred base image for ceph containers has been
Rocky Linux 10, and the CI tag-naming logic in build.sh already assumes
rockylinux-10 is the default fromtag for every branch except reef and
squid. The actual build default was never flipped, though: anything
that ran build.sh without FROM_IMAGE set (e.g. the release container
job in ceph-build) still got a CentOS Stream 9 base.
Flip the Containerfile ARG and the build.sh fallback to
docker.io/rockylinux/rockylinux:10 so umbrella and later build from
Rocky 10 by default. Builds that want a different base can still pass
FROM_IMAGE explicitly, as the CI pipeline does.
Signed-off-by: David Galloway <david.galloway@ibm.com>
This commit fixes an issue when the image is not the base distro,
the debug suffix for it is overwritten. This is especially
required for crimson debug builds to work for rocky10.
Fixes: https://tracker.ceph.com/issues/75952
Signed-off-by: Shraddha Agrawal <shraddha.agrawal000@gmail.com>
We build centos9 and rocky10 packages and containers by default now for wip, main, and tentacle branches as of https://github.com/ceph/ceph-build/pull/2557.
Starting with tentacle, we want a `podman pull quay.ceph.io/ceph-ci/ceph:tentacle` or `podman pull quay.ceph.io/ceph-ci/ceph:$SHA1` to get the container with Rocky 10 as the Base OS image, or FROM_IMAGE.
Fixes: https://tracker.ceph.com/issues/75673
Signed-off-by: David Galloway <david.galloway@ibm.com>
https://github.com/ceph/ceph-build/pull/2497 introduced a debug flavor.
This seems to cause conflicts with the image being pushed to quay as one
of the flavors might override the other.
Tag debug build containers explicitly.
Alternative solution would be to skip debug containers all together.
However. these might be useful for development purposes.
Note, prune-quay might also need to be updated once this is merged.
Signed-off-by: Matan Breizman <mbreizma@redhat.com>
'fromtag' is already available as distillation of the
FROM_IMAGE environment variable: everything after last
slash, s/:/-/. Use it as a suffix if it's anything other than
"centos-9stream" so that multiple CI container tags can coexist.
Signed-off-by: Dan Mick <dan.mick@redhat.com>
Update the build.sh script such that the environment variable
CUSTOM_CEPH_REPO_URL is passed to the container build command
as a build argument. This allows a developer or system outside of the
ceph CI to build container images similar to those produced by the
CI but using custom RPM packages.
Signed-off-by: John Mulligan <jmulligan@redhat.com>
Optionally, for those that want to run build.sh locally and
use the images. The default is to remove, for Jenkins builders,
which will build, push, and rmi.
Fixes: https://tracker.ceph.com/issues/70196
Signed-off-by: Dan Mick <dan.mick@redhat.com>
release builds were using the wrong container repo name because of
confused variable naming and inadequate separation. Keep the hostname,
org name, and repo name in separate variables, and assemble the full
path with a version when tagging is done.
Signed-off-by: Dan Mick <dan.mick@redhat.com>
- change repo path to prerelease
- remove image id arg for release push
- include 'v' in version name for release push
Signed-off-by: Dan Mick <dan.mick@redhat.com>
The wrong string was used for comparison, and for tagging,
so the arm64 branch and sha1 images overwrote and destroyed
the amd64 images.
Signed-off-by: Dan Mick <dmick@redhat.com>
The intent is to replace ceph-container.git, at first for ci containers
only, and eventually production containers as well.
There is code present for production containers, including
a separate "make-manifest-list.py" to scan for and glue the two
arch-specific containers into a 'manifest-list' 'fat' container,
but that code is not yet fully tested.
This code will not be used until a corresponding change to the
Jenkins jobs in ceph-build.git is pushed.
Note that this tooling does not authenticate to the container repo;
it is assumed that will be done elsewhere. Authentication is
verified by pushing a minimal image to the requested repo.
Signed-off-by: Dan Mick <dmick@redhat.com>
