Skip to main content

Monorepos and many repositories

A repository can hold several QA-Board projects, one per folder with a qaboard.yaml: each has its own results, batches and metrics, and inherits the configuration of the folders above it. Many repositories can also share one configuration.

Add a project in a folder of your repository​

Say your repository is kitefin/k3, with a qaboard.yaml at its root, and the denoiser lives in isp/denoise:

  1. Add a qaboard.yaml in the folder, with what differs from the root's. It can be empty.

    isp/denoise/qaboard.yaml
    inputs:
    batches: isp/denoise/batches.yaml
    outputs:
    metrics: isp/denoise/metrics.yaml
  2. Run qa from that folder.

    cd isp/denoise
    qa batch ci

    The results go to a new project, kitefin/k3/isp/denoise: the root project's name, then the folder. It's a subproject of the root project, kitefin/k3.

What subprojects share:

  • Configuration: isp/denoise/qaboard.yaml inherits everything from the root qaboard.yaml, deep-merged. Don't change project.name or project.url in a subproject.
  • Paths: relative paths in qaboard.yaml files are relative to the root's folder, and qa first changes its working directory to it.
  • Lists: a subproject's list replaces the root's. To add items, write super where the root's items go:
# qaboard.yaml
outputs:
visualizations:
- path: out.png

# isp/denoise/qaboard.yaml
outputs:
visualizations:
- super
- path: noise.plotly.json
#=> the subproject has the 2 visualizations

In run(), from qaboard.config import project, project_root, subproject tells you where you are.

Run subprojects in the CI​

Run each subproject's batch from its folder: cd isp/denoise && qa batch ci. What the CI sees carries the folder:

  • qa batch's commit status is QA denoise, with the name of the subproject's folder (see CI integration);
  • qa gate --post-status's is qaboard/gate/isp/denoise (see Quality gate);
  • qa check-bit-accuracy waits for the job named <bit_accuracy.failed_ci_job_name> denoise (see Bit accuracy).

If your CI only saves the build on some branches, tuning.branches can name them per subproject, with {subproject} (the folder, isp/denoise) and {subproject.name} (its last part, denoise): see Tuning from the web app. Integrations get ${subproject} too (see Integrations).

Submodules​

If a git submodule has its own qaboard.yaml, and the repository around it uses QA-Board too, qa would see the submodule as a subproject. Add root: true to the submodule's qaboard.yaml: qa stops looking for qaboard.yaml files above it.

Share a configuration between repositories​

A qaboard.yaml can include another: the included file is deep-merged under it. Its path is relative to the root qaboard.yaml's folder.

If you have many repositories, project-a, project-b..., that are always checked out next to a folder of shared files, each can include the shared configuration:

projects/project-a/qaboard.yaml
# projects/common holds the shared files
include: ../common/qaboard.yaml

project:
name: projects/project-a
url: git@github.com:projects/project-a

project.name and project.url can use Python's format syntax with 2 variables: root_path (the root qaboard.yaml's folder) and project_path (the subproject's folder). Every repository can then have the same file:

projects/project-a/qaboard.yaml
include: ../common/qaboard.yaml

project:
name: "projects/{project_path.name}"
url: git@github.com:your-organization/{project_path.name}
tip

project.description and project.avatar_url give each project a description and an avatar on the home page. Avatars from other hosts than your git hosts must be listed in QABOARD_PROXY_HOSTS.