Hi it is shown in the bash script that we can use -y option to specify the path of our yml file. However, when I use the -y option to place my yml file in a folder other than the root directory, Codecov fails to find it.
.travis.yml
after_success:
- bash <(curl -s https://codecov.io/bash) -y src/codecov.yml
src/codecov.yml
coverage:
status:
project:
default: false
components:
paths:
- 'src/components'
Hi @joshua0308 are you still seeing this issue? I’m seeing latest commits are finding the yml but at ./codecov.yml instead
Hi @tom! I moved my codecov.yml file back to the root because Codecov couldn’t find it when I had the yaml file under the src folder.
This is the commit where codecov.yml was placed inside the src folder. I use the -y flag, but it seems like it doesn’t find it and falls back to the latest valid yaml file. Thanks for your help!
@tom Can you check why the -y flag is not working? Ideally I don’t want the yaml file in my root directory. I had to move it to the root because -y flag did not work. Thanks!
Hi @joshua0308,
Thanks for your message and sorry it took so long to get back to you. Again, I appreciate the PR you opened on our bash uploader repository.
Unfortunately, the -y flag is being deprecated, and it’s my fault that we didn’t communicate this to you earlier. If you don’t want the yaml file in your root, you can move it to .github/ or dev/. Those are the only three places we will parse the yaml from on our backend.
Hey @tom - thanks for getting back. Maybe you have a better solution to what I am struggling with here.
Problem:
We have a monorepo at work that has a total of ~70 projects. Currently, our coverage ratio is for the entire repo which barely changes on individual PRs given the size of it. We would like to be more granular by encapsulating the coverage reports for each project.
Flags:
We thought about flagging each of our project but soon realized that it would mean our PR builds would be 70+ lines (each project having its own coverage check). Ideally we would like to see coverage checks only for the projects that the PR is concerned with.
Flags seem to work well with monorepos with a few projects, but for us it introduces too much noise into every PR given that we need 70+ flags.
Ideally we need a way to dynamically change the projects that would show up on coverage checks. The solution I came up with is to create a yaml file for each project and dynamically tell Codecov which yaml file to use at build time using the -y flag in the bash script.
For example, if I worked on a PR for project A, I would tell Codecov to use the yaml file in project A which allows me to get only the relevant coverage report.
bash <(curl -s https://codecov.io/bash) -y /projectA/codecov.yml
But given that the feature is now deprecated, I’m wondering what the best alternative solution would be. Our company’s been struggling to get this right for quite a bit now. Any help or insight would be appreciated!
Hi @joshua0308, I can imagine that getting 70 status checks on a PR is absolutely painful. Unfortunately, we don’t have an easy workaround for you now, but I’ve looped in the product team to add this to the next version of carryforward flags. I’m sorry I can’t give you a better answer for this right now, but I’ll update this thread as we make progress.
Hey @joshua0308 – just adding on that you are not alone, we are confirmed making a change to our UI accordingly in v2 of carryforward flags.
@jerrod Thanks for the response. I saw that it was listed under the upcoming roadmap when @tom gave his Zoom presentation. Looking forward to the new feature!
Hi @joshua0308, just an update here, we’ve released some new features with Carryforward Flags which should help with having less than 70 status checks. Here is the documentation for it, but you can just add
coverage:
status:
default_rules:
carryforward_behavior: “exclude”
to your codecov.yml file which should hide status checks for flags that have been carried forward. One note, if these status checks are required, you will still run into issues, because that status check might still be blocking.