AArnott / Library.Template

A template for a NuGet package with tests, stylecop, fxcop, versioning, and Azure Pipelines build ready to go.
MIT License
131 stars 26 forks source link

CodeCov bash uploader is deprecated #163

Closed SteveBush closed 2 years ago

SteveBush commented 2 years ago

The bash uploader for CodeCov has been deprecated and replaced with a platform-specific binary downloader.

https://docs.codecov.com/docs/supported-languages

I have started coding two Powershell scripts to replace the bash implementation in GitHub Actions and Azure Pipelines. The first script downloads and returns a path to the downloaded platform-specific codecov binary. The second script takes a codecov_token and path and uploads all code coverage files from this path.

I'm having a couple of challenges with Windows. The Windows codecov.exe has trouble with symbolic links and Windows style paths. The artifacts\coverageResults-Windows folder contains symbolic links.

Options: 1) Move CodeCov upload to wrap-up step where all of the code coverage files are downloaded and the Azure report is generated. No symbolic links to deal with up code cov uploads is later in build. 2) Make temporary copies of the code coverage artifacts and use that folder. 3) Figure out how to detect a Symbolic Link in PowerShell and return the target location. I think this is using the .Target property.

I'm also calling CodeCov once per report as the file globbing behavior is affected by the symbolic links. I would like to make one call but CodeCov doesn't know how to find symbolic links.

AArnott commented 2 years ago

Thanks for calling out this need, and for investigating the options!

Can we scope the .exe's search to include where the code coverage files originally are such that it isn't going to run across the symbolic links? The way the downloaded bash script works today, it doesn't seem to have a problem but I also suspect it just scans the entire source tree. How is it that this new Windows exe is discovering the coverageResults-Windows folder anyway, considering that isn't within the source tree when run on Azure Pipelines anyway? If you are pointing the exe at that artifact folder, can we simply point it at the source tree's test folder instead?

Otherwise of your 3 options my favorite is no. 1.

SteveBush commented 2 years ago

The published codeCoverage-[Platform] folder has all of the duplicate coverage files removed. The source tree contains duplicate copies of the code coverage files (see #162). The bash uploaded scanned the whole source tree looking for code coverage files.

I have option 3) implemented in my project. Here’s what it does:

1) Get-CodeCovTool.ps1. Downloads platform appropriate codecov binary via a PowerShell script. It has the same behavior as Get-nbgv.ps1. It downloads the tool into the temporary tool path. 2) publish-CodeCov.ps1. Search code coverage folder for published code coverage files. Handles Linux, MacOS, and Windows pathing and symbolic links. Calls codecov binary for each code coverage file it finds. Added parameters for codecov_token, code_coverage_path, name, and flags. Name allows you to name the coverage file, defaults to “”. I call it with “{Agent} Coverage Results”. Flags defaults to “” and I call it with “{Agent OS}, {Build_Configuration}”.

The advantage to this approach is that the build is in control of which code coverage files to publish. Also, you can specify flags which show up in the coverage reports.

I’m traveling now but I can send you the changes if you’re interested. Two PowerShell scripts and updates to GitHub build.yml and Azure dotnet.yml to remove bash calls and add call to PowerShell script.

AArnott commented 2 years ago

I am interested, thank you.

SteveBush commented 2 years ago

I created a pull request for you to review. #164 Let me know if you have any questions.