By default, packages built on cbs are just tagged to candidate tag and stay in cbs/koji.
If you want your packages to get pushed to the https://buildlogs.centos.org mirror pool, you can tag packages to testing
Warning
Worth knowing that while packages are served over https, and repositories metatdata signed, the packages aren't signed with gpg key at this time ! Also good to know that only classical pkgs are pushed out, so no src.rpm nor debuginfo packages are sent to testing network
If you want to tag multiple specific packages/versions to testing, you can proceed with one koji/cbs call :
cbs tag-build <sig_name>-<project>-<version>-testing <pkg1>-1.0.1 <pkg2>-2.3.4 <and_so_on>
This will trigger a message on the mqtt-based message bus and intercepted by the isolated machine processing requests. At this stage it will :
distRepo tasks (preparing a usable repository with your packages) and wait for it to finishbuildlogs CDNIn the next minutes, your up2date repository will appear on https://buildlogs.centos.org/centos/ and so following the tag convention :
<sig_name>/ ├── <architecture> │ ├── <project>-<version> │ │ ├── Packages │ │ └── repodata
As buildlogs.centos.org has its own specific cdn, you can point your users willing to test your packages directly to such url (in your .repo, see below)
Once you're satisfied with your package[s] quality (after some testing/feedback, up2you to decide when/how), you can proceed with next step, aka pushing to mirror network.
Same process as for testing except that it's now release tag :
cbs tag-build <sig_name>-<project>-<version>-release <pkg1>-1.0.1 <pkg2>-2.3.4 <and_so_on>
This will trigger a message on the mqtt-based message bus and intercepted by the isolated machine processing requests. At this stage it will :
distRepo tasks (preparing a usable repository with your packages) and wait for it to finishThe packages will appear on the existing mirror network, divided into three categories :
Starting from CentOS Stream 9, all packages will be pushed out in one simple directory. All packages will be appearing on http://mirror.stream.centos.org, under the SIGs directory (separated from distro content, for a clear distinction about distro versus SIGs generated content)
This is how it would look like for Stream 9 :
SIGs/9-stream/<sig_name>/ ├── <architecture> │ └── <project>-<version> │ ├── debug │ │ └── repodata │ ├── Packages │ └── repodata
When packages are signed and pushed to mirror network, they are automatically (for the release level) checked by the mirror crawler[s] and so you don't need to point your users to either mirror.stream.centos.org or mirror.centos.org.
Instead you can point to the correct mirrorlist or metalink url instead, depending on the CentOS Linux/Stream version :
You can call mirrorlist.centos.org by specifying the repo name, archictecture and centos version like this :
http://mirrorlist.centos.org?release=<centos_release>&arch=<arch>&repo=<sig_name>-<project>-<version>
Example for the configmanagement sig producing the ansible (project) 29 (version) repo :
curl 'http://mirrorlist.centos.org/?release=8&arch=x86_64&repo=configmanagement-ansible-29'
Starting from CentOS Stream 9 , mirrors are now added in Fedora Mirrormanager so you have to call metalink= instead of mirrorlist=
As MirrorManager has already plenty of fedora/epel repositories to track, the reponame to use to query mirrormanager for metalink is more complex than for previous mirrorlist.centos.org setup.
The logic goes like this :
repo=centos-<sig_name>-sig-<project>-<version>-9-stream&arch=<basearch>
And the whole metalink url being then (with the infra SIG producing the infra project with version common):
curl 'https://mirrors.centos.org/metalink?repo=centos-infra-sig-infra-common-9-stream&arch=x86_64'
To make it convenient for end-users to add both the .repo files used by dnf/yum to automatically find new repositories, and also to ship the dedicated rpm gpg public key to verify the gpg integrity of the shipped packages, SIGs can build and ship a centos-release-<sig> package.
Worth knowing that such packages have to be built through specific cbs tags (see below) and not your SIG tag.
Indeed, SIGs content aren't "trusted" by default (at the rpm gpg level) but 8-strea/9-stream will start distributing the rpm gpg public key that will sign these specific centos-release-* packages, and so end-users will be able to dnf install centos-release-<blah> directly.
Once done, end-users will be able to download/consume your repositories.
To do so, you can create first an infra ticket to create a project under the /rpms/ namespace on https://git.centos.org (in case it doesn't exist yet)
How should you name your 'centos-release' package ? Basically following the centos-release-<project> naming convention (see for example the openstack project, built by the Cloud SIG, and having multiple <versions> , each version for each supported centos distribution being a different branch)
At the minimum, your git project for your centos-release package should look like :
├── .centos-release-<project>.metadata
├── SOURCES
│ ├── CentOS-SIG-<project>.repo
│ └── RPM-GPG-KEY-CentOS-SIG-<name>
└── SPECS
└── centos-release-<project>.spec
You can then proceed as described previously to push to git and then submit a build against specific tags (verify through cbs list-permissions --mine that you can build/tag to specific 'extras' tags. If not, see with your SIG group chair/sponsor
Important
Don't submit your build to your own SIG tag : instead use the dedicated extras<8s,9s>-extras-common-release tag, that each SIG chair will be able to build for