Draft: Introduce build step to tmt

[thrix]

Warning

This is a draft, expect changes here, we will remove the Draft: from the title once it is ready.

Introduction

One of the confusing things for newcomers is the fact that tmt expects the tested artifacts (brew builds, copr builds, but also VM images and container images) to be existing before tmt is executed. Newcomers coming from traditional CI systems like GitHub Actions or Gitlab CI, where the build is part of the pipeline, is easy to add. The artifacts from the build pipeline are then used in the next phases of the pipeline to actually test them.

Moreover, we are seeing patterns where a step running before the first discover would provide additional benefits and make tmt design cleaner:

• it would provide another input that could be used in discover phase
• it could be used to include tested artifacts from remote locations
• it could provide input to the new artifact installation plugin, see Test artifacts installation #2226
• it could provide input to provision plugins

The build step

The new step would be first in the tmt pipeline, preceding discover step. The step would have multiple plugins implementing various ways to build or include test artifacts from remote locations or systems.

The artifacts created or included in the build step would be available to other steps to consume.

Examples

Shell build step

We build some artifact via an arbitrary script. The output directory is automatically synced to the hsot.

build:
    - how: shell
      script: ./build.sh
      output: ./artifacts

discover:
   how: tmt

provision:
   how: container
   image: quay.io/centos/centos:stream9
 
# The build artifacts are available under $TMT_TREE/artifacts
execute:
    how: tmt

Bootc

The new bootc provision plugin, which is being introduced in #3161, now does two things: build a qcow2 from a containerfile and boot it via virtual provisioner. With this new step, it would be more clearer what is really happening under the hood.

build:
    - name: mybootcvmimage
      how: bootc
      containerfile: Containerfile

discover:
   how: tmt

provision:
   how: virtual
   image: mybootcvmimage
 
execute:
    how: tmt

Container build

Here we build a container quay.io/project/container and run locally discovered tests against it.

build:
    # Build a container quay.io/project/container
    - how: buildah
      containerfile: Containerfile
      image: quay.io/project/container
     
discover:
   how: tmt

provision:
   how: container
   image: quay.io/project.container
 
execute:
    how: tmt

RPM build

We build a rpm via mock and install it in the container via the prepare install plugin.

build:
    # Build a container quay.io/project/container
    - name: myrpm
      how: mock
      chroot: epel-9-x86_64
      spec: myrpm.spec

discover:
   how: tmt

provision:
   how: container
   image: quay.io/centos/centos:stream9
 
 prepare:
    # The path to the rpms created by the build step is automatically synced to the test environment
    - how: install
      package: myrpm 
 
execute:
    how: tmt

Footnotes

This is something we talked about on DevConf with @cgwalters, and we believe could complete one of the missing pieces in the tmt testing pipeline. Also, it could be make tmt more attractive. I would like to thank him raising this issue to us.