From 9b81d96afd3468327f14bc6030c8ea606d6a2031 Mon Sep 17 00:00:00 2001 From: Fabian Arrotin Date: May 24 2023 11:58:14 +0000 Subject: Adding doc about spins/images and tag naming convention Signed-off-by: Fabian Arrotin --- diff --git a/docs/cbs.md b/docs/cbs.md index 2edc1ba..0ecf94e 100644 --- a/docs/cbs.md +++ b/docs/cbs.md @@ -61,10 +61,12 @@ Our koji tag structure *must* follow always the following structure (really for * `SIG` : SIG name , corresponding to IPA group, without the `sig-` prefix (so `sig-cloud` would become `cloud`) * `CentOS Version`: .el version, so el7 means CentOS 7, el8s means CentOS Stream 8, and so on - * `Project` : the project that the SIG want to build (example `openstack`) + * `Project` : the project that the SIG want to build (example `openstack`) (see note about `images` below) * `Version` : project version, can be a number or a string (example `yoga` for openstack version) * `repo variant|tag`: one of the following : candidate, testing or release (see Delivery about the meaning for these levels) +!!! note + If you want to create spins (qcow2, container, or else), `Project` has to be set to `images` as that's what is used by the sign and push process to see if that's something else then rpm packages/repositories that need to be processed ! Let's use one example, the `Cloud` SIG would like to build Openstack (Yoga release) for CentOS Stream 9 @@ -93,6 +95,16 @@ cbs build ---el git+https !!! note you can always submit a test build by adding `--scratch` to the build command as argument : that would really build the pkg but wouldn't make it available anywhere to be used. Please avoid using --scratch though as it consumes resources on the build systems for nothing +### non rpm artifacts (spins) + +There is a way to build something else than rpm packages in koji/cbs, even if that's the primary target (to then create usable repositories of signed packages). +Some SIGs want also to build a cloud image/iso image, or container, that contains their packages, and so that can be directly used by end users but you need to create some specific tags (through infra ticket, see below about the `images` project for your sig) + +CBS supports actually this through some plugins, including : + + * [kiwi](http://osinside.github.io/kiwi/) : you need to store some .xml files, following the kiwi naming convention and with a description and then you can call `cbs kiwi-build` followed by path to your .kiwi file (git+https:// path). Worth knowing that kiwi seems to support cearing container, iso hybrid live image, qcow2 virtual disk image, RootFS, so flexible enough (actually used by Hyperscale SIG) + * imagefactory : calling cbs with some options like `image-build`, `spin-livecd` or `spin-livemedia`). Not really tested recently though but you can read [upstream doc](https://docs.pagure.org/koji/image_build/) + ### cbs/koji common error messages #### Build already exists diff --git a/docs/delivery.md b/docs/delivery.md index 0ebee5d..e41ac16 100644 --- a/docs/delivery.md +++ b/docs/delivery.md @@ -5,6 +5,11 @@ Here is a quick overview of the Delivery process , from storing sources in git, ![CBS-SIGS-workflow](img/CBS-SIGs-workflow.png) +## Spins + +In the following sections we'll focus on rpm packages and repositories but worth knowing that spins artifacts will be signed themselves, but the SHA256SUM files will be, allowing to verify images integrity + + ## Promoting to testing By default, packages built on cbs are just tagged to `candidate` tag and stay in cbs/koji. diff --git a/docs/spin.md b/docs/spin.md index fbf60d8..6a7ba9f 100644 --- a/docs/spin.md +++ b/docs/spin.md @@ -17,7 +17,7 @@ Spins produced by a SIG should be documented on its wiki page as deliverables. CentOS spins are part of the CentOS Project, in the same way that other SIG deliverables are. Spins should strive to comply with all project policies, guidelines and best practices. SIGs are required to clearly identify spins as such, but are otherwise allowed to use the CentOS logo and name as part of spins they may produce like for any other deliverables. ## Distribution -Spin deliverables should be build in CBS and distributed via the mirror network. This isn't a requirement for experimental and work-in-progress deliverables, as long as they're clearly marked as such. +Spin deliverables should be built in CBS and distributed via the mirror network. This isn't a requirement for experimental and work-in-progress deliverables, as long as they're clearly marked as such. ## Discontinued spins SIGs should review the content they produce during their quarterly review. If the SIG has announced their intention to no longer maintain a spin, it will be removed from the mirrors.