-
Notifications
You must be signed in to change notification settings - Fork 549
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
feat(toolchain): Extend Python Testing Toolchain with COVERAGE_RC Support #2246
base: main
Are you sure you want to change the base?
feat(toolchain): Extend Python Testing Toolchain with COVERAGE_RC Support #2246
Conversation
c7a142b
to
173853e
Compare
4c0451e
to
5a16df4
Compare
5a16df4
to
039012f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is certainly interesting. It seems that there are //tests/python/python_tests.bzl
failing due to the mock module_ctx
not being updated.
Shall we mark this as Ready for review and ask others to also have a look? Before doing that could you please update the PR description?
I am going to work on the description and get the tests to pass, then we can open it up for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added some extra thoughts about the API design
039012f
to
0d3a405
Compare
f256992
to
9ebd564
Compare
The test under Bazel 6.4.0 test is failing. My guess is because this native java |
02d40e0
to
9e4665c
Compare
Ah, this is because bazel 6.4 is not using the starlark implementation of the rules, so it is expected to not work for now. |
0371be3
to
3060b83
Compare
Idea for why the Windows build is failing - it is using a very different bootstrap mechanism and it could be that the coveragerc is not wired properly. I am not 100% sure how we should do this. @rickeylev, any thoughts here? |
@rickeylev @aignas Figured out the issue |
de0204d
to
d7181bc
Compare
d7181bc
to
2270aa0
Compare
ping @aignas @rickeylev |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the general direction, but my main question is about how we could implement the additions of the toolchain so that we could have different flavours of py_test
.
@@ -6,6 +7,12 @@ load("@rules_python//python:defs.bzl", "py_binary", "py_test") | |||
load("@rules_python//python/config_settings:transition.bzl", py_versioned_binary = "py_binary", py_versioned_test = "py_test") | |||
load("@rules_shell//shell:sh_test.bzl", "sh_test") | |||
|
|||
IS_BAZEL_7_OR_HIGHER = version >= "7" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this can be dropped, we are no longer testing bazel 6 with bazelmod.
@@ -48,6 +48,9 @@ A brief description of the categories of changes: | |||
|
|||
{#v0-0-0-added} | |||
### Added | |||
* (toolchain) Using testing toolchain to configure py_test coverage. | |||
This opens the potential to configure differnt test runners. | |||
([#2246](https://github.com/bazelbuild/rules_python/pull/2246)). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to ensure that this gets updated, I think a rebase is needed.
# Add the environment from the target if it has RunEnvironmentInfo. | ||
# RunEnvironmentInfo contains environment variables configured by exec_group toolchain | ||
if RunEnvironmentInfo in target: | ||
env.update(target[RunEnvironmentInfo].environment) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a bug that is fixed by this PR or is it a new feature?
use_repo(python_test, "py_test_toolchain") | ||
register_toolchains("@py_test_toolchain//:all") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The python_test
extension in theory could register to toolchain itself, just like python
does it. What do you think?
python/private/py_executable.bzl
Outdated
@@ -326,6 +329,12 @@ def _get_runtime_details(ctx, semantics): | |||
direct.append(effective_runtime.coverage_tool) | |||
if effective_runtime.coverage_files: | |||
transitive.append(effective_runtime.coverage_files) | |||
if is_test: | |||
py_test_toolchain = ctx.exec_groups["test"].toolchains[PY_TEST_TOOLCHAIN_TYPE] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be something that is a parameter to this function. I am thinking that we could somehow allow users creating executable rules with their own toolchain types. I would love to be able to move toward the direction of #1647.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should use the ability to use a callback macro at the level of the toolchain. I didn't use that approach here since I was not adding an executable. Will change the implementation.
python/private/py_executable.bzl
Outdated
py_test_toolchain = ctx.exec_groups["test"].toolchains[PY_TEST_TOOLCHAIN_TYPE] | ||
if py_test_toolchain: | ||
coverage_rc = py_test_toolchain.py_test_info.coverage_rc | ||
extra_test_env = {"COVERAGE_RC": coverage_rc.files.to_list()[0].short_path} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think in general we should check the ctx.configuration.coverage_enabled
and add this in only then.
Regarding my comment above, if we would like to generalize it, do you have ideas how we could do it?
exec_groups = { | ||
"test": exec_group(toolchains = [config_common.toolchain_type(PY_TEST_TOOLCHAIN_TYPE, mandatory = False)]), | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally I would love to be able to express this as
exec_groups = { | |
"test": exec_group(toolchains = [config_common.toolchain_type(PY_TEST_TOOLCHAIN_TYPE, mandatory = False)]), | |
}, | |
extra_toolchains = [PY_TEST_TOOLCHAIN_TYPE], | |
extend_foo = _my_function_to_add_env_and_set_coverage, | |
exec_groups = { | |
"test": exec_group(toolchains = [config_common.toolchain_type(PY_TEST_TOOLCHAIN_TYPE, mandatory = False)]), | |
}, |
My goal is for us to extend py_test
with toolchain such that it would be possible to define a different flavour of py_test
with its own toolchain and for that we would be reusing the create_executable_rule
snippet like above.
Do you have any ideas?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on the C++ Testing Toolchain approach, it is better to have this configured at the toolchain level rather than the rule level. If I understand this correctly, users will be required to specify extend_foo
on every py_test
rule
I think I don't understand how _my_function_to_add_env_and_set_coverage
will access the information provided by the toolchain.
Inspired by https://github.com/trybka/scraps/blob/master/cc_test.md This PR extends Test Runner enviroment to provide a coveragerc enviroment variable COVERAGE_RC, allowing user to provide coverage resource in what ever format
Create partially-bound function for configuring py_test
2270aa0
to
acbd8c7
Compare
This PR enhances the Test Runner environment to support custom coverage configuration via the COVERAGE_RC environment variable. Inspired by this approach, this feature allows users to specify a .coveragerc file in any compatible format to customize coverage reporting.
Key Changes
Adds support for the COVERAGE_RC environment variable in the Test Runner environment.
Enables users to define and pass their own .coveragerc configurations, enhancing flexibility for various testing and reporting requirements.
close #1434