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 toscmsync
the contents from a subdirectory in the deployment branch.home:${OSC_USER}:CR:${OS_VERSION}
: A test project, which has a project widescmsync
to the deployment branch. Therefore it will automatically pick up every new package without manual intervention and it will also use the correctprjconf
via the_config
(this file is populated inwrite_all_image_build_recipes()
).home:${OSC_USER}:Staging:${OS_VERSION}:${branch_name}-${pr_num}
: The scratch build project created for each pull request againstmain
by the staging bot inscratch_build()
home:${OSC_USER}:BCI:CR:${OS_VERSION}:Staging:SUSE:BCI-dockerfile-generator:PR-${PR_NUM}
: projects created by OBS’ SCM CI fromhome: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
andworkflow
scopes. It is required to trigger mutable actions from slash-commands.