Redesign CI-jobs/pipelines metrics

[fniessink]

Context:

• Jenkins has jobs with builds or pipelines with builds. In the case of pipelines, the pipelines contain jobs/stages.
• GitLab has pipelines with runs. A pipeline can consist of jobs, which are stages of the pipeline. Each repo has one pipeline.
• Azure DevOps has pipelines with runs. In Azure DevOps a repo can have multiple pipelines. Pipelines have stages (called jobs).

Currently, Quality-time has four metrics that use Jenkins/GitLab/Azure DevOps pipelines and/or jobs as source:

• Failed CI-jobs
• Unused CI-jobs
• Job runs within time period
• Source up-to-dateness (for jobs)

Problems:

• The failed CI-jobs and unused CI-jobs both count jobs, only with different status, and could/should be one metric with a parameter to distinguish between the statuses.
• As the terminology differs between the three CI-tools, things are pretty confusing. Does the failed CI-jobs also support pipelines? Does it support jobs within pipelines? Etc.

Solution:
Create a new metric, to ultimately replace to current metrics: "Builds". Builds are runs of pipelines or jobs. The metrics counts the number of builds of the pipelines and/or jobs specified by the user. Description: "The builds metric counts the number of builds of pipelines or CI-jobs. Builds can be filtered by name, status, trigger, time period, and branch."

Parameters:

• The period in which to look for builds
• The statuses of builds
• The triggers of builds
• The branches built
• The name of the pipeline and/or job

Due to the confusing terminology, we first draft the data model before implementing the story.

Tasks:

• Create the data model for the "builds" metric.
• Review and refine

[fniessink]

This issue will be realized as part of #8972.