I was able to resolve this issue.

The Gitlab badge for test coverage will be scanning the latest successful pipeline logs for a specified branch (in my case a feature branch).

However, in my case, the Gitlab CI stage "test" had an only restriction in that it will only trigger on the master branch. So, I was previously creating a MR with this branch, and then manually triggering the pipeline. This will not classify as a pipeline running on a branch. Instead, Gitlab sees this as running on a merge request pipeline.

The solution to this was to either remove the restriction that the CI stage will only run on the master branch by removing that line of code within Gitlab CI. Or in my case, whitelisting the name of the feature branch to the list in the only field. Now, when you push a new change to the branch, the pipeline should automatically trigger (even without a MR open) and if you have the test coverage total amount printed out in the logs, along with the relevant regex, then the data should be able to be caught by the Gitlab Badge.

Okay it looks like that I need to add also -main to only part of my .gitlab-ci.yml and then it works. I was just maybe hoping I can have it without running tests twice (before MR to main and after).

I finally got the coverage badge displaying a percentage instead of unknown today for my python project. Here's the relevant content from my .gitlab-ci.yml:

job:
 script:
  - 'python -m venv venv'
  - '.\venv\Scripts\activate'
  - 'python -m pip install -r requirements.txt'
  - 'coverage run --source=python_project -m unittest discover ./tests'
  - 'coverage report --omit=things_that_arent_mine/*'
  - 'coverage xml'
 artifacts:
  reports:
   cobertura: 'coverage.xml'

I'm also using the regex for gcovr listed in the repo CI/CD Settings > General Pipelines > Test coverage parsing which I found after reading this as well as the second to last comment on this:

^TOTAL.*\s+(\d+\%)$

In the repo General Settings > Badges, my badge link is:

http://gitlab-server/%{project_path}/-/jobs

and my badge image url is:

http://gitlab-server/%{project_path}/badges/%{default_branch}/coverage.svg

I don't quite know what the Cobertura report artifact is for (I think it specifically has to do with merge requests) but I have it in there because the tutorials took me down that road. I did confirm that removing the following from the .gitlab-ci.yml doesn't break the badge or coverage number on the jobs page:

  - 'coverage xml'
 artifacts:
  reports:
   cobertura: 'coverage.xml'

While removing or commenting:

- 'coverage report --omit=things_that_arent_mine/*'

does break the badge as well as the coverage number displayed on the CI/CD jobs page of the repo. I also tried some regex variations that I tested in rubular but the only one that didn't cause gitlab to barf was the gcovr one.

Hopefully this helps out, it was kind of difficult and arduous to piece together what was needed for this badge to work on a python project.

EDIT: Also just figured out how to add some sexy precision to the coverage percentage number. If you change the coverage report line of the .gitlab-ci.yml to:

- 'coverage report --omit=things_that_arent_mine/* --precision=2'

And the regex in CI/CD Settings > General Pipelines > Test coverage parsing to:

^TOTAL.+?(\d+.\d+\%)$

That should give you a very precise coverage number that effectively no one but you and I will care about. But by gosh we'll know for sure if coverage is 99.99% or 100%.

I know this is an old question, but this may help others see this question in the future. Except setting the Test Coverage parsing regex in the Settings, CI/CD page, you need to make sure the test coverage percent is printed somewhere in the CI's console log. The printed line should match the given regex. So, Gitlab can parse and save it as the code coverage percent.

I've answered with more detail the same question: Gitlab coverage badge always unknow

I was struggling with this too for a python project and found that the test coverage results is now deprecated (https://docs.gitlab.com/ee/ci/pipelines/settings.html#add-test-coverage-results-to-a-merge-request-deprecated)

The answer for me was to use the coverage keyword in my .gitlab-ci.yml with the required regex to extract the percentage from the job log

e.g.

test:
  stage: test
  extends: .python-reports
  script:
    - pipenv run pytest --cov --cov-report term-missing --cov-report xml:./coverage_out_report.xml --junitxml=./test_out_report.xml
  coverage: '/TOTAL.*\s+(\d+%)$/'

And my badge defined as

Link https://gitlab.com/%{project_path}/-/commits/%{default_branch}

Badge image URL https://gitlab.com/%{project_path}/badges/%{default_branch}/coverage.svg

Now I see the coverage as 100% on main (or master) and a nice green badge

Gitlab CIs Test coverage report badge shows unknown when no coverage information was obtained.

This is certainly the error condition, e.g. you expect to have at least some different match here (good / acceptable / medium / low).

For it to work, the job log must contain at least one line (the last would be taken) that matches the regular expression form the job keywords coverage key word.

You coverage regular expression is:

/^\s*Lines:\s*\d+.\d+\%/

This regular expression has to match the coverage percentage number (incl. zero) and the match may contain surrounding text.

The actual number for the badge is matched by \d+(\.\d+)? on your regular expression match.

The most detailed description about how this regular expression works can be obtained from the coverage key word documentation.

As you have not shared any job log that you expect your regular expression to match against not much specifically can be said.

It appears as a configuration issue to me, and it is either that the expectation is wrong that it would match against the job log output while it does not (you can easily validate this with a regular expression test tool either on your box or online at https://regex101.com/) - or - there is a match but the matched number can not be parsed by Gitlab CI (which from my own feeling is less likely).

If you have a match of a line of your job log, then verify that match as the subject against the match of another regular expression, \d+(\.\d+)?, as that is the one Gitlab uses to obtain the actual number.