[FrontPage] [TitleIndex] [WordIndex

This is a read-only archived version of wiki.centos.org

There are 2 points in the process where packages can be promoted for wider consumption. Testing content can be distributed to the buildlogs.centos.org content delivery network for developers and CI systems to consume. Release-ready content can be promoted to a SIG-specific directory on mirror.centos.org for consumption by end-users.

As a first step, decide on the final release location of the repo on mirror.centos.org. You can use the same path for buildlogs.centos.org.

Pushing Test Content to Buildlogs

The new signing and push process in place since 2020-03-25 doesn't require anything than just tagging pkgs to -testing repository.

As soon as you will have "tag-built" packages to -testing, that will trigger a distRepo task on koji and also a push to buildlogs.centos.org Assuming that your tag is "cloud7-openstack-train-testing", and that you have three archictectures enabled (x86_64,ppc64le and aarch64) that means that it will appear on

Releasing content to mirror.centos.org

1. Steps to request space on the mirror network

Same process as for -testing, except that current process is getting notification that pkgs are tagged in -release tag, and so would push to mirror.centos.org network (and so external mirrors) and also sign packages with correct SIG GPG key.

It will also push debuginfo pkgs to debuginfo.centos.org and src.rpm packages to vault.centos.org

Worth noting that for CentOS 7 only, x86_64 will be pushed to mirror.centos.org/centos/$path while other arches like ppc64le/ppc64/aarch64 will be pushed to mirror.centos.org/altarch/$path. The $contentdir yum variable can be used in your .repo files to select the branch (centos or altarch).

centos-release Packages

To deliver SIG packages to users, the yum repo files must be available in a package named centos-release-<component>. This centos-release-<component> package will be published in the CentOS Extras repository. That .repo file should also contain the gpg public key that permits signing validation of the downloaded artifacts from mirror nodes.

For example the cloud sig releases OpenStack Rocky using the repo definitions in centos-release-openstack-rocky.

1. Building a centos-release-* package
  1. If you are a new SIG and don't have an assigned SIG gpg key (also with public key listed on https://www.centos.org/keys/#community-driven-project-keys) , you should file a bug report on https://pagure.io/centos-infra/issues/

Once you have received your gpg pub key, you can start composing your centos-release--* sig pkg.

  1. Ask for the centos-release-<SIG> pkg to be created a as repo on https://git.centos.org (for example https://git.centos.org/rpms/centos-release-openstack) : file a request on https://pagure.io/centos-infra/issues/

  2. Set up your content sources in the .repo file. For example, centos-release-openstack-rocky could have this definition for the main repository:
    name=CentOS-7 - OpenStack rocky
    There can also be other repositories defined in the .repo file, for example for testing, debuginfo and sources. See the other centos-release-* packages for examples. The above example uses mirrorlist.centos.org for selecting the closest external mirror. Using mirrors obtained via mirrorlist.centos.org is preferred, because it gives the user the fastest possible mirrors and decreases load from mirror.centos.org servers. The baseurl to CentOS-controlled mirror.centos.org is still available as a commented out backup. Note the use of $contentdir to select either centos or altarch.

    The repo parameter to mirrorlist.centos.org is constructed from the path by dropping the architecture and changing slashes to dashes. For example, files in cloud/x86_64/openstack-rocky can be found from a repository named cloud-openstack-rocky, and files in sclo/x86_64/rh/rh-python36 can be found from sclo-rh-rh-python36. Please make sure you get the path and repo names right in your .repo file. Content on mirror.centos.org is scanned every three hours, and any new repositories will be added automatically to the mirror crawler database.

  3. If this is the first build, add the new centos-release-mycomponent to the Extras tags
    [bstinson@localhost centos-release-mycomponent]$ cbs add-pkg --owner=bstinson core7-extras-common-candidate centos-release-mycomponent
    [bstinson@localhost centos-release-mycomponent]$ cbs add-pkg --owner=bstinson core7-extras-common-testing centos-release-mycomponent
    [bstinson@localhost centos-release-mycomponent]$ cbs add-pkg --owner=bstinson core7-extras-common-release centos-release-mycomponent
  4. Build the package in CBS against the Extras tag
    [bstinson@localhost centos-release-openstack-mycomponent]$ cbs build core7-extras-common-el7.centos centos-release-mycomponent-0.0.1-1.rpm
  5. File a bug to request content to be synced to mirror.centos.org (See SIGGuide#MirrorSpace)

  6. Tag the build to the testing tag
    [bstinson@localhost centos-release-openstack-mycomponent]$ cbs tag-build core7-extras-common-testing centos-release-mycomponent-0.0.1-1
  7. Do a test yum install of a package from the new repo

  8. When ready, tag the build to the release tag
    [bstinson@localhost centos-release-openstack-rocky]$ cbs tag-build core7-extras-common-release centos-release-mycomponent-0.0.1-1

2. Some Guidelines for centos-release-* packages
  • centos-release-* packages should be built as noarch RPMs

2023-09-11 07:23