suse-edge/Factory
SHA256
14
0
Fork 15
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Updates SUSE Edge 3.2 branch with updated Kiwi image builder base #124

Closed
roxenham wants to merge 1 commits from roxenham/Factory:kiwi-image-6.0 into 3.2
pull from: roxenham/Factory:kiwi-image-6.0
merge into: suse-edge:3.2
Conversation 5 Commits 1 Files Changed 2 +12 -12
2 changed files with 12 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
kiwi-builder-image/Dockerfile
View File

@@ -1,6 +1,6 @@
#!BuildTag: %%IMG_PREFIX%%kiwi-builder:10.1.16.0 #!BuildTag: %%IMG_PREFIX%%kiwi-builder:10.2.12.0
#!BuildTag: %%IMG_PREFIX%%kiwi-builder:10.1.16.0-%RELEASE% #!BuildTag: %%IMG_PREFIX%%kiwi-builder:10.2.12.0-%RELEASE%
FROM registry.suse.com/bci/kiwi:10.1.16 FROM registry.suse.com/bci/kiwi:10.2.12
dirkmueller commented 2025-04-22 13:58:19 +02:00
Review
Copy Link

I wonder if this shouldn't be 10.2 - the 10.2.12 is not going to be "maintained" regularly by updates (it will stop seeing updates as soon as kiwi 10.2.13+ is being submitted and released). there is a floating tag "10.2" which refers to the latest "10.2.x" (as well as a "10" tag which would refer to any kiwi 10.x.y version.

I wonder if this shouldn't be `10.2` - the 10.2.12 is not going to be "maintained" regularly by updates (it will stop seeing updates as soon as kiwi 10.2.13+ is being submitted and released). there is a floating tag "10.2" which refers to the latest "10.2.x" (as well as a "10" tag which would refer to any kiwi 10.x.y version.
fdegirmenci commented 2025-04-22 15:39:34 +02:00
Review
Copy Link

As this is a released version, I wonder if it makes sense to pin to the specific version, 10.2.12, rather than the floating tag, 10.2, which might change without us noticing + making it difficult to reproduce if the issues occur as what we include in the release this week might not be the same with what customers might be using in 2 months from now.

Edit after thinking a minute - this might not be an issue actually considering we won't be changing the image after the release but pinning to a specific version for the release purposes still makes sense to me.

As this is a released version, I wonder if it makes sense to pin to the specific version, `10.2.12`, rather than the floating tag, `10.2`, which might change without us noticing + making it difficult to reproduce if the issues occur as what we include in the release this week might not be the same with what customers might be using in 2 months from now. Edit after thinking a minute - this might not be an issue actually considering we won't be changing the image after the release but pinning to a specific version for the release purposes still makes sense to me.
dirkmueller commented 2025-04-22 17:55:53 +02:00
Review
Copy Link

I think we have a mismatch between what we build and what we document here. I agree we shouldn't necessarily document people to use the very latest image if that hasn't been validated. so pinning that makes sense until there is control in releasing only working images.

However, for building we do need to find latest image. also on every z stream release I think we should be updating to the latest image becaues it includes other fixes.

BTW you're not actually pinning the image. the "10.2.12" tag is floating as well, as long as there are only rebuilds of the container. if you want to pin you would actually have to pin a specific build. so you already have that issue, you just don't know about it.

I think we have a mismatch between what we build and what we document here. I agree we shouldn't necessarily document people to use the very latest image if that hasn't been validated. so pinning that makes sense until there is control in releasing only working images. However, for building we do need to find latest image. also on every z stream release I think we should be updating to the latest image becaues it includes other fixes. BTW you're not actually pinning the image. the "10.2.12" tag is floating as well, as long as there are only rebuilds of the container. if you want to pin you would actually have to pin a specific build. so you already have that issue, you just don't know about it.
fdegirmenci commented 2025-04-22 18:01:55 +02:00
Review
Copy Link

BTW you're not actually pinning the image. the "10.2.12" tag is floating as well, as long as there are only rebuilds of the container. if you want to pin you would actually have to pin a specific build. so you already have that issue, you just don't know about it.

Aha, this is news to me. Thanks for the info!

> BTW you're not actually pinning the image. the "10.2.12" tag is floating as well, as long as there are only rebuilds of the container. if you want to pin you would actually have to pin a specific build. so you already have that issue, you just don't know about it. Aha, this is news to me. Thanks for the info!
MAINTAINER SUSE LLC (https://www.suse.com/) MAINTAINER SUSE LLC (https://www.suse.com/)
# Define labels according to https://en.opensuse.org/Building_derived_containers # Define labels according to https://en.opensuse.org/Building_derived_containers
@@ -12,7 +12,7 @@ LABEL org.opencontainers.image.version="%PACKAGE_VERSION%"
LABEL org.opencontainers.image.url="https://www.suse.com/solutions/edge-computing/" LABEL org.opencontainers.image.url="https://www.suse.com/solutions/edge-computing/"
LABEL org.opencontainers.image.created="%BUILDTIME%" LABEL org.opencontainers.image.created="%BUILDTIME%"
LABEL org.opencontainers.image.vendor="SUSE LLC" LABEL org.opencontainers.image.vendor="SUSE LLC"
LABEL org.opensuse.reference="%%IMG_REPO%%/%%IMG_PREFIX%%kiwi-builder:10.1.16.0" LABEL org.opensuse.reference="%%IMG_REPO%%/%%IMG_PREFIX%%kiwi-builder:10.2.12.0"
LABEL org.openbuildservice.disturl="%DISTURL%" LABEL org.openbuildservice.disturl="%DISTURL%"
LABEL com.suse.supportlevel="%%SUPPORT_LEVEL%%" LABEL com.suse.supportlevel="%%SUPPORT_LEVEL%%"
LABEL com.suse.eula="SUSE Combined EULA February 2024" LABEL com.suse.eula="SUSE Combined EULA February 2024"

16
kiwi-builder-image/README
View File

@@ -8,7 +8,7 @@ Please ensure that you're running this on a registered SLE Micro 6.0 system, and
Next, download the podman image: Next, download the podman image:
# podman pull %%IMG_REPO%%/%%IMG_PREFIXkiwi-builder:10.1.16.0 # podman pull %%IMG_REPO%%/%%IMG_PREFIXkiwi-builder:10.2.12.0
Make a local output directory (where the images will reside): Make a local output directory (where the images will reside):
@@ -16,32 +16,32 @@ Make a local output directory (where the images will reside):
Then, to build a standard "Base" image, run the following in podman: Then, to build a standard "Base" image, run the following in podman:
# podman run --privileged -v /etc/zypp/repos.d:/micro-sdk/repos/ -v ./output:/tmp/output -it %%IMG_REPO%%/%%IMG_PREFIXkiwi-builder:10.1.16.0 build-image # podman run --privileged -v /etc/zypp/repos.d:/micro-sdk/repos/ -v ./output:/tmp/output -it %%IMG_REPO%%/%%IMG_PREFIXkiwi-builder:10.2.12.0 build-image
To build a "Base" SelfInstall ISO, you can add additional flags, for example: To build a "Base" SelfInstall ISO, you can add additional flags, for example:
# podman run --privileged -v /etc/zypp/repos.d:/micro-sdk/repos/ -v ./output:/tmp/output -it %%IMG_REPO%%/%%IMG_PREFIXkiwi-builder:10.1.16.0 build-image -p Base-SelfInstall # podman run --privileged -v /etc/zypp/repos.d:/micro-sdk/repos/ -v ./output:/tmp/output -it %%IMG_REPO%%/%%IMG_PREFIXkiwi-builder:10.2.12.0 build-image -p Base-SelfInstall
Then, to build a standard "Default" image, run the following in podman: Then, to build a standard "Default" image, run the following in podman:
# podman run --privileged -v /etc/zypp/repos.d:/micro-sdk/repos/ -v ./output:/tmp/output -it %%IMG_REPO%%/%%IMG_PREFIXkiwi-builder:10.1.16.0 build-image -p Default # podman run --privileged -v /etc/zypp/repos.d:/micro-sdk/repos/ -v ./output:/tmp/output -it %%IMG_REPO%%/%%IMG_PREFIXkiwi-builder:10.2.12.0 build-image -p Default
To build a "Default" SelfInstall ISO, you can add additional flags, for example: To build a "Default" SelfInstall ISO, you can add additional flags, for example:
# podman run --privileged -v /etc/zypp/repos.d:/micro-sdk/repos/ -v ./output:/tmp/output -it %%IMG_REPO%%/%%IMG_PREFIXkiwi-builder:10.1.16.0 build-image -p Default-SelfInstall # podman run --privileged -v /etc/zypp/repos.d:/micro-sdk/repos/ -v ./output:/tmp/output -it %%IMG_REPO%%/%%IMG_PREFIXkiwi-builder:10.2.12.0 build-image -p Default-SelfInstall
To build an image with a RealTime kernel, e.g. a RAW disk image ("Default"), use the following: To build an image with a RealTime kernel, e.g. a RAW disk image ("Default"), use the following:
# podman run --privileged -v /etc/zypp/repos.d:/micro-sdk/repos/ -v ./output:/tmp/output -it %%IMG_REPO%%/%%IMG_PREFIXkiwi-builder:10.1.16.0 build-image -p Base-RT # podman run --privileged -v /etc/zypp/repos.d:/micro-sdk/repos/ -v ./output:/tmp/output -it %%IMG_REPO%%/%%IMG_PREFIXkiwi-builder:10.2.12.0 build-image -p Base-RT
To build an image that supports a large block/sectorsize (4096), use the "-b" flag, for example: To build an image that supports a large block/sectorsize (4096), use the "-b" flag, for example:
# podman run --privileged -v /etc/zypp/repos.d:/micro-sdk/repos/ -v ./output:/tmp/output -it %%IMG_REPO%%/%%IMG_PREFIXkiwi-builder:10.1.16.0 build-image -p Default-SelfInstall -b # podman run --privileged -v /etc/zypp/repos.d:/micro-sdk/repos/ -v ./output:/tmp/output -it %%IMG_REPO%%/%%IMG_PREFIXkiwi-builder:10.2.12.0 build-image -p Default-SelfInstall -b
# mkdir mydefs/ # mkdir mydefs/
# cp /path/to/SL-Micro.kiwi mydefs/ # cp /path/to/SL-Micro.kiwi mydefs/
# cp /path/to/config.sh mydefs/ # cp /path/to/config.sh mydefs/
# podman run --privileged -v /etc/zypp/repos.d:/micro-sdk/repos/ -v ./output:/tmp/output -v ./mydefs/:/micro-sdk/defs/ -it %%IMG_REPO%%/%%IMG_PREFIXkiwi-builder:10.1.16.0 build-image # podman run --privileged -v /etc/zypp/repos.d:/micro-sdk/repos/ -v ./output:/tmp/output -v ./mydefs/:/micro-sdk/defs/ -it %%IMG_REPO%%/%%IMG_PREFIXkiwi-builder:10.2.12.0 build-image
All output will be in the local $(pwd)/output directory, for example: All output will be in the local $(pwd)/output directory, for example: