You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If we have packages that don't depend on each other, I don't know how to skip them.
(For now, I want to run the CI for native_assets_cli and c_compiler on PRs to both packages anyway. c_compiler immediately imports native_assets_cli, and the example in native_assets_cli imports c_compiler.)
Coverage badge is per whole repo, not per package.
(Current setup makes the coverage for a single package and ignoring the other.)
Possibly there is a way to let coveralls combine the results from multiple jobs. https://pub.dev/packages/mono_repo seems to indicate some support, but I'm not sure how to map that to the current workflows.
None of the listed mono_repo packages on the package documentation actually have coverage (badges).
(Slightly off-topic: Another thing to consider is to not split jobs at all, the packages need the same dependencies installed to run, installing those deps takes time as well.)
cc @kevmoo (as main contributor to package:mono_repo) Do we have a good story for package:mono_repo and properly working Coveralls reports? Should I be using mono_repo generate over manually making GitHub workflows? I'd love to learn more about how to set this up properly.
@dcharkes – I added coverage a while ago. It works!
# When using `test_with_coverage`, this setting configures the service that
# results are uploaded to.
# Note: you can configure both options, but this would be unusual.
# Note: you can configure this key with no values, to just generate the files
# locally. This may be to enable other, custom processing.
coverage_service:
# https://coveralls.io/ - the default
- coveralls
# https://codecov.io/ – the other option
- codecov
After #13, we have what we need. In a more concise fashion than using the mono_repo generator. So we're just going to stick with the manual workflow file for now.
We currently have two workflows, one for each package.
We should consider merging them into a single workflow using a matrix.
Pros:
Cons:
native_assets_cli
andc_compiler
on PRs to both packages anyway. c_compiler immediately imports native_assets_cli, and the example in native_assets_cli imports c_compiler.)Possibly there is a way to let coveralls combine the results from multiple jobs.
https://pub.dev/packages/mono_repo seems to indicate some support, but I'm not sure how to map that to the current workflows.
None of the listed mono_repo packages on the package documentation actually have coverage (badges).
(Slightly off-topic: Another thing to consider is to not split jobs at all, the packages need the same dependencies installed to run, installing those deps takes time as well.)
edit: trying to switch Coveralls to monorepo:
job list: https://coveralls.io/repos/400800/builds
edit 2: Having merged the last PR to main, I can see two builds for main:
Both of them report the correct coverage for the respective packages, but they are not aggregated correctly.
Based on https://github.com/marketplace/actions/coveralls-github-action, maybe it would work if we do a
carryforward
. (The next question then is if we can get badges for the individual packages.)edit 3: trying to see what
mono_repo generate
would do as configuration: https://gist.github.com/dcharkes/338f175398ed0300151b5aa48ea3f878Also a single file.
The text was updated successfully, but these errors were encountered: