Builders

1. Add a new builder

Let's assume that the new builder will be named kojibuilder10.dev.centos.org

Enable builder on the hub (From koji doc : "Make sure you do this before you start kojid for the first time, or you'll need to manually remove entries from the sessions and users table before it can be run successfully"). This step has to be done with a user having koji admin right, and can be done with a simple koji client, so not on the koji hub node itself.

 export new_koji_builder="kojibuilder10.dev.centos.org"
 koji add-host ${new_koji_builder} i386 x86_64
 koji add-host-to-channel ${new_koji_builder} createrepo
 koji edit-host --capacity=20 ${new_koji_builder}

If the builder will use Image Factory :

 koji add-host-to-channel ${new_koji_builder} image

Generate CERT for that new node on the FAS server (manual step : cd /var/lib/centos-ca ; ./gen-node-cert.sh )
Add those key/cert file in the pkistore used by Puppet
Deploy a new host/VM , and register it in Foreman/puppet
Ensure that the NFS/storage server permits the new builder to get access to the kojishare
Assign koji-builders config group to that host in Foreman
- Override the following variables :
  - ::koji::builder::kojid_kojifiles_url: (to point to the url of koji hub , example http://dev-koji.lon1.centos.org/kojifiles)
  - ::koji::builder::kojid_xmlrpc_url: (to point to the url of koji hub , example http://dev-koji.lon1.centos.org/kojihub)
  - ::koji::mount::koji_local_mountpoint: (where to mount the nfs shared repo used by koji , example /mnt/kojishare)
  - ::koji::mount::koji_nfs_path: (full path to server exporting the nfs koji share, example : storage01.lon1.centos.org:/srv/kojishare)
  - ::koji::pkistore::koji_pki_cert: CA certificate used to sign the koji cert, example : fas-dev-ca-cert.pem
  - ::koji::pkistore::koji_pki_client_cert: Certificate generated for the builder at the FAS level, example kojibuilder10.dev.centos.org .crt (has to match !)
  - ::koji::pkistore::koji_pki_client_key: private key that was used to generate the crt signed by the CA cert, example kojibuilder10.dev.centos.org .key (has to match)
  - ::koji::pkistore::koji_pki_env: prod or dev (default value = prod)
  - ::koji::builder::kojid_maxjobs : number of jobs that this builder can support (optional, default puppet value = 20)
  - ::koji::builder::kojid_minspace : minimum free filesystem space (in Mb) under which kojid will refuse to start and so accepting jobs (optional, default puppet value = 8192)

Bootstrap new koji instance

If you want to bootstrap a new instance for test, you can use the standard sig_creation tool but you need first to create the external repos it expects :

$ su - koji
$ koji add-external-repo centos6-os                "http://mirror.centos.org/centos/6/os/\$arch/"
$ koji add-external-repo centos6-updates           "http://mirror.centos.org/centos/6/updates/\$arch/"
$ koji add-external-repo centos5-updates           "http://mirror.centos.org/centos/5/updates/\$arch/"
$ koji add-external-repo centos5-os                "http://mirror.centos.org/centos/5/os/\$arch/"
$ koji add-external-repo centos6-extras            "http://mirror.centos.org/centos/6/extras/\$arch/"
$ koji add-external-repo centos7-os                "http://mirror.centos.org/centos/7/os/\$arch/"
$ koji add-external-repo centos7-updates           "http://mirror.centos.org/centos/7/updates/\$arch/"
$ koji add-external-repo centos7-extras            "http://mirror.centos.org/centos/7/extras/\$arch/"
$ koji add-external-repo sclo7-bootstrap           "http://cbs.centos.org/externalrepos/sclbootstrap/7/"
$ koji add-external-repo sclo6-bootstrap           "http://cbs.centos.org/externalrepos/sclbootstrap/6/"

You can get the actual list of repos on a production instance :

$ su - koji 
$ koji list-external-repos

Maintenance

1. Add a new tag for an existing SIG

WARNING : always specify -c when SCL are involved

As koji user you can run :

$ /opt/cbs-tools/scripts/create_sig.sh       
usage: templates/cbs-tools/scripts/create_sig.sh -d <distribution> -s <signame(s)> -t <tag(s)>

This script generate new build target in koji for SIGS.

OPTIONS:
   -a   ARCHES                   : Force arches e.g : "x86_64","aarch64 i686", etc...
   -b                            : Enable non public bootstrap repo (SCLO SIG only)
   -c   COLLECTION               : Enable collection in the buildroot e.g : mariadb100
   -d   DISTRIBUTION             : 5 6 7 8 8s
   -p   SIG PROJECT NAME         : cloud6-<openstack>, sclo-<mariadb100>, etc...
   -r   SIG PROJECT RELEASE NAME : cloud6-openstack-<juno>
   -s   SIG NAME                 : cloud
   -t   DISTTAGS                 : "el7 el7.centos el8_0"
   -x                            : delete old -build tag and then recreate.

For example to add a new tag for version 8 of opendaylight, nfv SIG you can run :

$ /opt/cbs-tools/scripts/create_sig.sh -s nfv -d 7 -p opendaylight -t el7 -r 8

Please note that the disttag is important and you can check previous version of the project if user forgot to mentioned it. Otherwise confirm with the SIG Chair.

A note about CentOS stream, The "el8s" dist tag is needed as koji has a unique namespace for packages.

To add a new tag for version CentOS Stream 8 of opendaylight, nfv SIG you can run :

$ /opt/cbs-tools/scripts/create_sig.sh -s nfv -d 8s -p opendaylight -t el8s -r 8

Specific note for SCLs (SCLo or RH ones) :

Don't forget to create tags with "-c" from script to automatically add scl_build to buildroot (needed)

For the signing+push operations, it happens through one specific tag, so each newly created tag for SCL needs to be added to the -all- tag. Here is a snippet to do this :

basetag="sclo7-rh-nodejs14-rh"
scl_tag="rh" # can be sclo or rh depending on collections
for i in testing release; do
 last_priority=$(koji taginfo sclo7-all-${scl_tag}-${i}|tail -n 1 | awk ' {print $1}')
 new_priority=$(( $last_priority + 5 ))
 koji add-tag-inheritance sclo7-all-${scl_tag}-${i} ${basetag}-${i} --priority ${new_priority}
done

When they request also a tag inheritance (like rh-nodejs14 inherits from devtoolset-9), it can be done through the el7-build and candidate tags inheritance :

koji add-tag-inheritance sclo7-rh-nodejs14-rh-el7-build sclo7-devtoolset-9-rh-candidate --priority 15

2. Ensuring we have default pkg in buildroot

In case we need by default some pkgs in the buildroot, we can use the following (example) :

koji add-group-pkg infra8-buildtools-common-el8-build build epel-rpm-macros
koji add-group-pkg infra8-buildtools-common-el8-build srpm-build epel-rpm-macros

3. Rebuild a package for a different arch

Build as a scratch build the previous .src.rpm, mention the wanted arch :

koji build --arch-override="ppc64 ppc64le aarch64" --scratch <target> <mysrpm>

Merge the build, with task id that was produced by previous command :

koji call mergeScratch <mytaskid>

4. Adding dependency on external repo[s] for some tags

$ koji add-external-repo --tag=opstools7-common-el7-build centos7-extras

5. Add a package to a buildroot

$ koji show-groups opstools8-collectd-5-el8-build
$ koji add-group-pkg opstools8-collectd-5-el8-build srpm-build go-srpm-macros
$ koji add-group-pkg opstools8-collectd-5-el8-build build go-srpm-macros

See an example at https://github.com/CentOS/ansible-role-kojihub/pull/4/files to make it permanent for the next time a SIG new project is created.

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