Staging Bot

Pull requests to the project are tested using a bot running via github actions. It writes all build recipes for the images to a branch and creates a staging project on https://build.opensuse.org/ under the user pushman (bot account of the container team). The bot will then write a comment in the pull request for each OS version that had changes with the branch name, the staging project URL and wait for the builds in the staging project to finish. Once they have finished, it will update the comment with the build results and either pass or fail the CI job depending on how the containers built on OBS. The bot will delete the previously created staging project and branches on each new push or when the PR is closed/merged.

For further details, see StagingBot or refer to the help of the command poetry run scratch-build-bot.

Branch setup

The source code of the generator and all utilities lives in the main branch, while the build recipes are written into separate, so called, deployment branches in this repository. For openSUSE Tumbleweed that is the tumbleweed branch and for SLE these are sle15-sp$SERVICE_PACK_NUMBER. All of these branches are protected on Github and only allow to be updated via pull requests.

The staging bot uses the deployment branches as a base to run test builds and will create new branches with the name $deployment_branch-$random_ASCII for pull requests against main. The bot will write the new build recipes once a pull request for main has been merged into the branch for-deploy-$deployment_branch and create a pull request against the respective deployment branch. Here we leverage OBS’ SCM CI to branch the packages from the CR project (continuous_rebuild_project_name) using the .obs/workflows.yml generated by the staging bot (obs_workflows_yml).

Project Setup

The current CI setup includes the following projects:

  • devel:BCI:${OS_VERSION}: The final build recipes reside in this project. Each package is created via scratch-build-bot.py setup_obs_package which sets up the package to scmsync the contents from a subdirectory in the deployment branch.

  • home:${OSC_USER}:CR:${OS_VERSION}: A test project, which has a project wide scmsync to the deployment branch. Therefore it will automatically pick up every new package without manual intervention and it will also use the correct prjconf via the _config (this file is populated in write_all_image_build_recipes()).

  • home:${OSC_USER}:Staging:${OS_VERSION}:${branch_name}-${pr_num}: The scratch build project created for each pull request against main by the staging bot in scratch_build()

  • home:${OSC_USER}:BCI:CR:${OS_VERSION}:Staging:SUSE:BCI-dockerfile-generator:PR-${PR_NUM}: projects created by OBS’ SCM CI from home:pushman:CR:${OS_VERSION} for every pull request against the deployment branches.

Secrets/Credentials

The CI currently requires the following credentials and access tokens to operate:

SCM Token

An SCM access token is required to trigger the webhook for updating the development and CR projects. Create such a GitHub Personal Access Token (PAT) following the guide in https://openbuildservice.org/help/manuals/obs-user-guide/cha-obs-scm-ci-workflow-integration#sec-obs-obs-scm-ci-workflow-integration-setup-token-authentication-how-to-authenticate-obs-with-scm The personal access token is then used to create a SCM token on OBS as follows:

osc token --create --operation workflow --scm-token $PAT

OBS will respond with an xml response as the following:

<status code="ok">
    <summary>Ok</summary>
    <data name="token">$SECRET</data>
    <data name="id">$ID</data>
</status>

The token value $SECRET is the webhook secret and the id $ID is the query parameter id in the Payload URL.

Staging Bot Account

Some actions on OBS cannot be triggered by the SCM integration, so we have to resort to use a less privileged account for this. The username is defined via the environment variable OSC_USER in the github actions yaml and the accompanying password is set in the secret OSC_PASSWORD.

Repository Access Tokens

Two access tokens are required

  • The PAT secret is a personal access token with the repo:public_repo scope. It is required to update comments triggered from slash-commands.

  • The CHECKOUT_TOKEN secret is a personal access token with the repo and workflow scopes. It is required to trigger mutable actions from slash-commands.