.. _staging-bot: 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 :py:class:`~staging.bot.StagingBot` or refer to the help of the command :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 (:py:attr:`~staging.bot.StagingBot.continuous_rebuild_project_name`) using the :file:`.obs/workflows.yml` generated by the staging bot (:py:attr:`~staging.bot.StagingBot.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 :command:`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 :file:`_config` (this file is populated in :py:func:`~staging.bot.StagingBot.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 :py:func:`~staging.bot.StagingBot.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: .. code-block:: shell-session osc token --create --operation workflow --scm-token $PAT OBS will respond with an xml response as the following: .. code-block:: xml Ok $SECRET $ID 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.