ttm

ToTest-Manager

ToTest-Manager has two stages:

• Releaser: Release a built product from the main project into the test subproject
• Publisher: Publish the tested product in the test subproject

Both stages can run independently, but they communicate using the ToTestManagerStatus attribute to avoid races, like releasing a product while it's being published or overwriting a product while it's being tested. The releaser publish disables the test subproject before releasing a product.

Products

There are various kinds of product types:

• main: Built in the main project in the product_repo for the given architectures and released into the product_repo in the test subproject. Optionally, it uses the OBS set_release option to set the build number of the products on release. On publish, the product_repo in the test subproject is publish enabled.
• livecd: Like main, but uses the :Live subproject's livecd_repo as source.
• ftp: Like main, but does not use set_release.
• image: Like main, but released into the totest_images_repo in the test subproject. On publishing, the totest_images_repo is publish enabled.
• container: Like main, but released into the totest_container_repo instead, which is always publish enabled so that they can be fetched from the OBS registry during testing. For publishing, those products are released into the releasetarget of totest_container_repo. This is best combined with a kind="maintenance_release" as the target project, to keep older builds instead of overwriting them. For long-living projects, container-cleaner.py is run which deletes older images.
• containerfile: Like container, but taken from a repo called containerfile instead, where container images are built using Dockerfile recipes.

Every product can have multiple architectures defined, those are only used to check for build success before doing a release. If any of the listed architectures failed to build, a release is blocked.

OBS does not allow to release a multibuild container without all of its flavors, so mentioning a multibuild container itself can be used instead of listing all flavors explicitly. In that case, there is no check for build success for the individual flavors, unless they are listed in addition.

There is a check to ensure that every successful build in the product_repo maps to a product. If this is not the case, an error is printed and the release is blocked.

set_release

The set_release mechanism can be enabled for main, livecd and image products, where their build number is overwritten by snapshot_number_prefix + a number. If take_source_from_product is set, that number is taken from the first main product (product_repo + product_arch) or if that doesn't exist, the first image product (first arch). Otherwise, the 000release-packages:(base)-release package from the main project's standard repo and arch is looked at.

Configuration

The configuration is stored in the ToTestManagerConfig attribute in YAML format.

base: openSUSE # Defaults to the toplevel project name
test_subproject: ToTest
do_not_release: False # If set, publishing is a noop (and the releaser doesn't publish disable!)
need_same_build_number: False # See set_release above
set_snapshot_number: False # See set_release above
snapshot_number_prefix: Snapshot # See set_release above
take_source_from_product: False # See set_release above
arch: x86_64 # See set_release above
jobs_num: 42 # Minimum number of openQA jobs before publishing is possible

product_repo: images
product_arch: local # See set_release above
livecd_repo: images
totest_container_repo: containers
totest_images_repo: images # Repo for image_products. If not set, uses product_repo.

products:
  main:
  - foo:dvd
  livecd:
  - livecd-foo:
    - x86_64
  ftp:
  - foo:ftp
  image:
  - foo:kvm:
    - x86_64
  - foo-container-image:lxc:
    - x86_64
  container:
  - foo-container-image:docker:
    - x86_64
  containerfile:
  - some-dockerfile:
    - x86_64