CentOS Stream Source-git Bot Deployment Specifics

Production

Production instance runs in stream-prod project @ auto-prod cluster. It serves gitlab.com/redhat/centos-stream/src/ repos. A group webhook is set to send "Merge request events" to the API.

redhat-internal-test-package

There's a package called redhat-internal-test-package which sole purpose of existence is to be used for dist-git / source-git experiments.

• Upstream repository
• CentOS Stream Dist-git
• CentOS Stream Source-git

To see how the (production) bot works, fork the source-git repo, do some update in code, commit, push to your fork, and create a merge request against the repo you forked from.

Example: https://gitlab.com/redhat/centos-stream/src/redhat-internal-test-package/-/merge_requests/1

Staging

Staging instance runs in stream-stg project @ auto-prod cluster (API) and is used to serve some repos in our packit-service/src/ namespace. Because we can't use Group Webhooks there to set up the service for whole namespace, currently only some repos are served, for example:

• open-vm-tools: source-git MR → dist-git MR
• luksmeta: source-git MR → dist-git MR
• glibc

There are actually real staging src-git and dist-git repos in redhat/centos-stream/staging namespace, but we haven't used them yet, because the CI (Pipelines) there don't seem to work the same way as in prod repos, so we use repos in our namespace (see above), because we have at least full control over them.

gitlab_webhook.py can be used to generate secret tokens to be used for setting up webhooks.

CI @ staging

In order for us to be able to experiment with syncing CI results from a dist-git MR back to a source-git MR, we have a fake CI setup. There's a .gitlab-ci.yml stored in both, the source-git and dist-git repos served by the staging service. In a source-git repo it's in .distro/ (example) and before the service creates a dist-git MR from a source-git MR the file is synced into the dist-git repo. Once the dist-git MR is created the pipeline is run based on the file and the results are seen in the dist-git MR. It's stored also in the dist-git repo (example), so that the file is not in a diff of a newly created dist-git MR as a newly added file.

How to add another staging package (to be serviced by staging bot)

This is how I just added cloud-init:

• create empty https://gitlab.com/packit-service/src/cloud-init & https://gitlab.com/packit-service/rpms/cloud-init projects
• git clone https://gitlab.com/redhat/centos-stream/src/cloud-init.git; cd cloud-init
• git remote add stg git@gitlab.com:packit-service/src/cloud-init.git
• git push --tags -u stg
• in https://gitlab.com/packit-service/src/cloud-init/-/hooks add a webhook pointing to https://stg.stream.packit.dev/api/webhooks/gitlab with secret generated by gitlab_webhook.py and 'Merge request events' trigger only.
• cd /your-path-to-dist-git-dir/
• git clone https://gitlab.com/redhat/centos-stream/rpms/cloud-init.git; cd cloud-init
• git remote add stg git@gitlab.com:packit-service/rpms/cloud-init.git
• git push --tags -u stg
• login to gitlab.com as packit-as-a-service-stg user (I know, but there's AFAIK no easier way since the detached pipeline runs in a fork) and add a webhook pointing to https://stg.stream.packit.dev/api/webhooks/gitlab with secret generated by gitlab_webhook.py and 'Pipeline events' trigger only.
• add some .gitlab-ci.yml (see above section for reason) to src/cloud-init/.distro and rpms/cloud-init, commit and push to stg (remote)

Now fork packit-service/src/cloud-init, do a change, create an MR.

Syncing dist-git MR CI results back to a src-git MR

prod

The notification about a change of a pipeline's status is sent to a group webhook (with "Pipeline events" trigger) which is manually added to the redhat/centos-stream/rpms group.

staging

For staging, a project webhook is added to forks in packit-as-a-service-stg namespace, because that's where a pipeline runs in case of non-premium plan (packit-service/rpms/ namespace).