Support arbitrary regex-captured test outputs in addition to coverage
Description
GitLab projects currently support defining a regular expression used to capture a coverage metric from the build outputs (found in project settings, CI/CD Pipelines, Test coverage parsing setting). This pulls a coverage metric from the build output and is displayed next to the build result on the pipelines view. (Issue #20428 (closed) extended this to allow defining the regex in .gitlab-ci.yml
and has been merged.)
I use GitLab for automatically grading student submissions, and currently I hijack this feature to acquire a grade output by my unit tests run on each build. Thus, for my students the "Coverage" column of the build results shown in the pipelines view shows their percent grade for the build instead of a coverage metric. This is fine, although it is confusing, and since there is only one such feature to hijack it's not possible for me to support a grade as well as an actual coverage metric or other arbitrary metrics simultaneously.
Proposal
Add the ability to define arbitrary fields in .gitlab-ci.yml
each of which can be given a name and a regular expression. Identically to how the current coverage regular expression feature currently works, the custom regular expression would populate the custom-named field with the value pulled from the build output and display a column for that field name in the build results shown in the pipelines view.
References
There are some existing issues that touch on this topic but do not appear to be going in the same direction as my suggestion. Issue #29396 (closed) does talk about being able to define custom fields and display them in the build results but it does not actually suggest providing this functionality by way of custom-defined fields in .gitlab-ci.yml
using regular expressions. Instead, that issue gave no particular suggestion for how to achieve it, and it was closed in favor of issue #13227 (moved), which seems to be in progress. The latter issue recommends a feature to be able to view arbitrary build artifacts, and yes it is a good feature recommendation, but this does not at all replicate the ability to define custom fields with arbitrary regular expressions used to parse them out of the outputs.