Skip to content
GitLab
Next
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 44,761
    • Issues 44,761
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,329
    • Merge requests 1,329
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #17633
Closed
Open
Issue created Mar 29, 2017 by Max Raab@maxraab🎯

Remove project setting for ci coverage detection

Release notes

To simplify the specification of a coverage pattern, in 15.0 the project setting for Test Coverage is being removed. Using the project’s .gitlab-ci.yml, provide a regular expression using the coverage keyword to set Testing Coverage in Merge Requests.

Background:

Since we can specify the coverage pattern in gitlab-ci.yml, we don't need the project setting any more.

What is the backstory of this project and how does it impact the approach?

Currently we have two places to set up the coverage pattern, which is a duplicate setting:

  • project settings -> CI/CD Pipelines -> Test coverage parsing
  • in gitlab-ci.yml

What do you already know about the areas you are exploring?

@godfat commented in gitlab-ce#27911:

I think it makes sense to remove that feature, but I am worried that it would break people's workflow. If we're removing it, we'll need to do it in major release and notify people beforehand.

What does success look like at the end of the project?

  • no duplicate settings
  • changes to gitlab-ci.yml are synced to forks of the project - project settings not

Links / references:

gitlab-ce#27911, gitlab-ce#28748

Edited Feb 04, 2022 by Jackie Porter
Assignee
Assign to
Time tracking