Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CI] mono_repo GitHub workflow setup with Coveralls #10

Closed
dcharkes opened this issue Apr 18, 2023 · 3 comments
Closed

[CI] mono_repo GitHub workflow setup with Coveralls #10

dcharkes opened this issue Apr 18, 2023 · 3 comments
Labels
type-infra A repository infrastructure change or enhancement

Comments

@dcharkes
Copy link
Collaborator

dcharkes commented Apr 18, 2023

We currently have two workflows, one for each package.

We should consider merging them into a single workflow using a matrix.

Pros:

Cons:

  • 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.)

edit: trying to switch Coveralls to monorepo:

image

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/338f175398ed0300151b5aa48ea3f878

Also a single file.

@dcharkes
Copy link
Collaborator Author

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.

@kevmoo
Copy link
Member

kevmoo commented Apr 20, 2023

@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

@dcharkes dcharkes added the type-infra A repository infrastructure change or enhancement label Apr 26, 2023
@dcharkes
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type-infra A repository infrastructure change or enhancement
Projects
None yet
Development

No branches or pull requests

2 participants