Coverage changes do not load

Support Bug Fixes
1

Description

I am not able to view coverage changes line by line. When clicking the file name under Coverage Changes here, I get a spinning circle which never loads. The coverage information seems correct, it’s just a shame that I can’t view the specifics.

Commit SHAs

ef80faaa840dff74eedd9294f27b3d9ee5c28abe

Repository

pyoptsparse

CI/CD or Build URL

Azure Pipelines

Uploader

Bash

Codecov Output

  _____          _
 / ____|        | |
| |     ___   __| | ___  ___ _____   __
| |    / _ \ / _` |/ _ \/ __/ _ \ \ / /
==> git version 1.8.3.1 found
==> curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.53.1 zlib/1.2.11 libidn/1.28 libssh2/1.8.0
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp 
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz unix-sockets 
==> Azure Pipelines detected.
    project root: .
    Yaml not found, that's ok! Learn more at http://docs.codecov.io/docs/codecov-yaml
==> Running gcov in . (disable via -X gcov)
==> Python coveragepy exists disable via -X coveragepy
    -> Running coverage xml
==> Searching for coverage reports in:
    + .
    -> Found 1 reports
==> Detecting git/mercurial file structure
==> Reading reports
    + ./coverage.xml bytes=124357
==> Appending adjustments
    https://docs.codecov.io/docs/fixing-reports
    + Found adjustments
==> Gzipping contents
        20K	/tmp/codecov.dmwsRc.gz
==> Uploading reports
    url: https://codecov.io
    query: branch=&commit=48f42ee20ec2ad437a2d527730ef0fb350b499a9&build=20210516.1&build_url=https%3A%2F%2Fdev.azure.com%2Fmdolab%2FPublic%2F_build%2Fresults%3FbuildId%3D1253&name=&tag=&slug=mdolab%2Fpyoptsparse&service=azure_pipelines&flags=&pr=252&job=1253&cmd_args=&project=Public&server_uri=https://dev.azure.com/mdolab/
->  Pinging Codecov
https://codecov.io/upload/v4?package=bash-1.0.2&token=secret&branch=&commit=48f42ee20ec2ad437a2d527730ef0fb350b499a9&build=20210516.1&build_url=https%3A%2F%2Fdev.azure.com%2Fmdolab%2FPublic%2F_build%2Fresults%3FbuildId%3D1253&name=&tag=&slug=mdolab%2Fpyoptsparse&service=azure_pipelines&flags=&pr=252&job=1253&cmd_args=&project=Public&server_uri=https://dev.azure.com/mdolab/
->  Uploading to
https://storage.googleapis.com/codecov/v4/raw/2021-05-16/9A9E88C3260DD229B43553E8188F23FF/ef80faaa840dff74eedd9294f27b3d9ee5c28abe/2fb4f130-4158-41a4-aa4c-9860cc461fcb.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=GOOG1EQM3VGPYSAFECJRMNAFIPCV2R3P2BOORCJC7NM537NPJQSFLHUDNIDWA%2F20210516%2FUS%2Fs3%2Faws4_request&X-Amz-Date=20210516T170515Z&X-Amz-Expires=10&X-Amz-SignedHeaders=host&X-Amz-Signature=600a9751d522fc4b82364f23d24e06dc4f5258e9a2bf367509fb939eb7f004ec
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 18742    0     0  100 18742      0  63785 --:--:-- --:--:-- --:--:-- 63748
    -> Reports have been successfully queued for processing at https://codecov.io/github/mdolab/pyoptsparse/commit/ef80faaa840dff74eedd9294f27b3d9ee5c28abe
Finishing: Coverage

Expected Results

View exactly which lines lost/gained coverage on the web UI

Actual Results

The web UI does not load.

Additional Information

I have tested this on both Firefox and Chromium, same result on both.

2

@nwu63 I think this is a path fixing issue. Try adding this to your codecov.yml file

fixes:
  - "pyoptsparse/::"

It might also be

fixes:
  - "pyoptsparse/pyoptsparse/::pyoptsparse/"

Let me know if either works

3

Hi Tom, thanks for the response. The test are run inside Docker, so the project root directory is actually located at /home/mdolabuser/repos/pyoptsparse. As a result, the current YAML file already has (via organizational YAML file)

fixes:
  - "/home/mdolabuser/repos/::"

I just tried "/home/mdolabuser/repos/pyoptsparse/::" and that didn’t seem to work.

4

It’s also worth pointing out that the fix listed above generates valid coverage reports. See for example here.

5

Hi @nwu63, I’m sorry this slipped off my radar entirely. I noticed that it seemed to be working on a later PR. Did you end up finding a solution to this?