Blame docs/cbs.md

80c633
# Koji/CBS buildsystem
2d9703
2d9703
## CBS permissions
2d9703
2d9703
!!! important
2d9703
    Before being able to submit build tasks to koji/cbs, you need to have a valid [account](auth.md) and be member of a SIG group ! So be sure you followed all steps described in [doc](auth.md) before trying any other step
2d9703
2d9703
If you followed the needed steps to get your account and your workstation prepared with needed packages and TLS certs in place, we can proceed with basic validation.
2d9703
2d9703
Let's try first to confirm that we can reach CBS/koji and be authenticated (assuming that your username is `user` :
2d9703
2d9703
```
2d9703
# cbs hello
2d9703
2d9703
g'day, <user>!
2d9703
2d9703
You are using the hub at https://cbs.centos.org/kojihub/
2d9703
Authenticated via client certificate /home/<user>/.centos.cert
2d9703
2d9703
```
2d9703
2d9703
Now, if you're member of a SIG group (identified as `sig-<groupname>` , the following command should list your all your rights and you should see a corresponding `build-<groupname>` permission : 
2d9703
2d9703
```
2d9703
# cbs list-permissions --mine
2d9703
build
2d9703
livecd
2d9703
appliance
2d9703
image
2d9703
build-configmanagement
2d9703
livemedia
2d9703
2d9703
```
2d9703
2d9703
As you can see, cbs/koji is using a 1:1 relationship between FAS/ACO group membership (sig-<groupname>) and the corresponding permissions to submit tasks against specific tags (see below) associated with that SIG.
2d9703
2d9703
!!! note
2d9703
    Just worth knowing that when you're added to a SIG group it can take just some minutes due to replication between FreeIPA servers and fasjson.fedoraproject.org to catch up, as that's the endpoint that cbs.centos.org is using to compute/modify rights. So just keep that in mind and wait for permissions to be returned as shown above before trying anything else
2d9703
2d9703
2d9703
## Understanding tags and targets
2d9703
2d9703
### Koji naming convention
2d9703
2d9703
A `build target` specifies the buildroot and destination of a package for submission. That means that as a user you ask koji to build a package within a specific build environment (build target) that is using a specific buildroot to find dependencies, etc. 
2d9703
A `Tag` is how koji is grouping packages all together, and built packages can be automatically added to a tag after a successfull build, or added manually between other tags with the `tag-build` koji task. 
2d9703
2d9703
### CBS SIGs tags structure
2d9703
2d9703
As you understood, each `build target` in CBS koji instance will have at least four tags : 
2d9703
2d9703
  * the -build one (which is where pkg is built and using the configured buildroot)
2d9703
  * three levels that will be used to promote packages after :
2d9703
    * candidate (default tag where built packages are tagged to)
2d9703
    * testing 
2d9703
    * release
2d9703
2d9703
Our koji tag structure *must* follow always the following structure (really for CBS, not the rule for koji but it's important for automation and release to mirror network steps) :
2d9703
2d9703
`<SIG><CentOS_version>-<Project>-<Version>-{candidate,testing,release}` , where:
2d9703
2d9703
  * SIG : SIG name , corresponding to IPA group, without the `sig-` prefix (so `sig-cloud` would become `cloud`)
2d9703
  * CentOS Version: .el version, so 7 means CentOS 7, 8s means CentOS Stream 8, and so on
2d9703
  * Project : the project that the SIG want to build
2d9703
  * Version : project version, can be a number or a string
2d9703
  * repo variant: one of the following : candidate, testing or release (see Delivery about the meaning for these levels)
2d9703
2d9703
2d9703
Let's use one example, the `Cloud` SIG would like to build Openstack (Yoga release) for CentOS Stream 9
2d9703
2d9703
The build target would be `cloud9s-openstack-yoga-el9s` and the tags would be : cloud9s-openstack-yoga-{candidate,testing,release}
2d9703
2d9703
2d9703
2d9703
### Submit a build on CBS
2d9703
2d9703
Before being able to submit a build task in koji, one has to be the pkg owner for it for all possible tags, so if you want to become the "owner" of a pkg for your own SIG/group, you can proceed like this (and replace `ACO_name`, `pkg_name` and `basetag` with real values :
2d9703
2d9703
```
2d9703
for level in candidate testing release ; do
2d9703
  cbs add-pkg --owner=<ACO_name> ${<basetag>}-${level} <pkg_name>
2d9703
done
2d9703
```
2d9703
2d9703
Now you can submit a build task by pointing to git.centos.org URL, pointing to project to build and git commit hash (assuming that you proceeded with needed steps in the [git](git.md) part :
2d9703
2d9703
```
2d9703
cbs build git+https://git.centos.org/rpms/<pkg_name>.git#<commit_hash>
2d9703
```
2d9703
2d9703
!!! note
2d9703
    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
2d9703
2d9703
2d9703
### Promoting packages to mirror network
2d9703
2d9703
See dedicated [Delivery](delivery.md) documentation