# Delivery

## Promoting to testing

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 : 

  * call koji for a `distRepo` tasks (preparing a usable repository with your packages) and wait for it to finish

  * sign repomd.xml file once repositories are all processed for all architectures

  * push that to the `buildlogs` CDN

In 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)

## Promoting to release and mirrors

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 : 

  * verify which packages need to be signed with the dedicated gpg key for the <sig>

  * download , sign and import back into koji signed packages

  * call koji for a `distRepo` tasks (preparing a usable repository with your packages) and wait for it to finish

  * sign repomd.xml file once repositories are all processed for all architectures

  * push various packages to mirrors, depending on the CentOS Version (see below) :

### CentOS Linux 7 and CentOS Stream 8

The packages will appear on the existing mirror network, divided into three categories :

  * 'normal' rpm packages (that people will download/install) => pushed to mirror.centos.org (and picked up by external mirrors too)

  * debuginfo rpm packages => pushed to https://debuginfo.centos.org 

  * src.rpm packages => pushed to https://vault.centos.org

### CentOS stream 9 and above

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

```

## Consuming rpms packages through .repo definition

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 : 

### CentOS Linux 7 and CentOS Stream 8

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'

```

### CentOS Stream 9 and above

Starting from CentOS Stream 9 , mirrors are now added in [Fedora Mirrormanager](https://admin.fedoraproject.org/mirrormanager/mirrors/CentOS) 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'

```

### centos-release-<sig> package

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](https://pagure.io/centos-infra/issues) 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](https://git.centos.org/rpms/centos-release-openstack/branches), 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](git.md) to push to git and then [submit a build](cbs.md) 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