GitLab PM here. Great point on #2 about the regex. We have an open issue (https://gitlab.com/gitlab-org/gitlab/-/issues/21549) to parse more data from an uploaded coverage report and coverage percentage seems like a great first step so you don't have to mess around with the regex.

-James H, GitLab Product Manager, Verify:Testing

It would be fine if you could for example pick up cobertura reports or maybe some other coverage formats (Golang reports, Xcode coverage reports) I know I can do this with all my Jenkins plug-ins. And maybe GitLab does not want to do all of this and people should use Sonarqube instead. But it is hard to go to GitLab when I have seen the light with Jenkins.

Cobertura is the first target report since it's the format that's supported by the Test Coverage Visualization feature (https://docs.gitlab.com/ee/user/project/merge_requests/test_...).

I'll make sure the other report types are on our list of future iterations as well.

Thanks!

-James H, GitLab Product Manager, Verify:Testing

GitLab Product Manager here - We’re working on ways to run fewer tests OR only the necessary tests earlier in a pipeline so you get to a result in fewer minutes. The first project towards this in the product is https://docs.gitlab.com/ee/user/project/merge_requests/fail_... which we hope to bring down to the Core tier soon.

-James H, GL Product Manager, Verify:Testing

I think most test runners have a --stop-on-failure feature, but using it has the downside of not giving you the complete list of failing tests.

If you haven't touched your gitlab pipelines for a few months, check out DAG pipelines [0] - I got my web project deployment pipeline down from 25 to ~12 minutes by running tests sooner.

[0] https://docs.gitlab.com/ee/ci/directed_acyclic_graph/

GitLab Product Manager here - The Codeclimate engine that out CodeQuality feature uses does support about half of the same languages as SuperLinter through plugins that can be added in the codeclimate.yml file. We are exploring how to support the missing languages and add output to the existing and future CodeQuality features.

We have also seen that SuperLinter can be run as part of a GitLab pipeline without too much hassle.

-James H Product Manager - Testing

You can see how to do so here, if interested: https://gitlab.com/snippets/1988376

Hi there!

GitLab Product Manager here. I really appreciate the feedback on those features and it helps inform some upcoming work to make them better. The team is currently working on improvements to JUnit parsing (https://gitlab.com/groups/gitlab-org/-/epics/2854) so we can enable those Junit reports by default.

We are also working on the next set of code coverage features to build this category out further and would appreciate any input you might have on the issues there as we're prioritizing and scheduling for the next few milestones (https://gitlab.com/groups/gitlab-org/-/epics/100).

Thanks!

-James H Product Manager - Testing

Hi there!

GitLab Product Manager here. You can generate code coverage reports today and use the generated value to populate a project badge value (https://docs.gitlab.com/ee/ci/pipelines/settings.html#test-c...) or publish the report(https://about.gitlab.com/blog/2016/11/03/publish-code-covera...).

We understand these are not the only use cases for code coverage and really just scratch the surface. We are working on the next set of features to build this category out further and would appreciate any input you might have on the issues there(https://gitlab.com/groups/gitlab-org/-/epics/100).

Thanks!

-James H Product Manager - Testing