Skip to content

Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Support
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
GitLab FOSS
GitLab FOSS
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 1
    • Issues 1
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Packages
    • Packages
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issues
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GitLab.org
  • GitLab FOSSGitLab FOSS
  • Issues
  • #20428

You need to sign in or sign up before continuing.
Closed
Open
Opened Jul 29, 2016 by Grzegorz Bizon@grzesiek🔴
  • Report abuse
  • New issue
Report abuse New issue

Make it possible to define a coverage regexp in job's configuration in YAML

Currently we can configure coverage regexp in CI/CD Pipeline settings, but since GitLab Runner has a parallel nature and we are not able to configure on which job GitLab has to look at, this may be unusable when someone parallelizes tests heavily (like we do).

One solution for that would be to move definition of coverage regexpfrom UI settings to.gitlab-ci.yml`. When someone defines:

rspec:
  variables: 
    SIMPLE_COV: 1
  script: rspec
  coverage: /(\d+.\d+\%) covered/ 

If this regexp will match against build log, job will have this coverage. If multiple jobs will have coverage regexp configured, we will use arithmetic mean, exactly like we do that now.

With that approach, however, we are able to exclude irrelevant jobs. Making this globally definable and job-level overridable we can maintain 100% backward compatibility.

What do you think @ayufan @markpundsack @tmaczukin?

Linked issues

  • Discussion
  • Designs
Assignee
Assign to
8.17
Milestone
8.17
Assign milestone
Time tracking
None
Due date
None
4
Labels
Community contribution customer direction feature
Assign labels
  • View project labels
Reference: gitlab-org/gitlab-foss#20428