-
Notifications
You must be signed in to change notification settings - Fork 539
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(coverage): Register coverage.py to hermetic toolchains #977
Commits on Jan 30, 2023
-
Configuration menu - View commit details
-
Copy full SHA for 8faed9b - Browse repository at this point
Copy the full SHA 8faed9bView commit details -
Configuration menu - View commit details
-
Copy full SHA for b9c0988 - Browse repository at this point
Copy the full SHA b9c0988View commit details -
feat(coverage): Add a script to manage coverage.py dependencies
This is managing the URL, names and sha256 value for the registered repositories.
Configuration menu - View commit details
-
Copy full SHA for f4e48dc - Browse repository at this point
Copy the full SHA f4e48dcView commit details -
feat(coverage): register coverage for supported python toolchain vers…
…ions Use coverage.py v6.5.0 because the latest has `types.py` in the package directory, which imports from Python's stdlib `types` [1]. Somehow the Python interpreter is thinking that the `from types import FrameType` is referring to the currently interpreted file and everything breaks. I would have expected the package to use absolute imports and only attempt to import from `coverage.types` if we use `coverage.types` and not just a plain `types` import. [1]: https://github.com/nedbat/coveragepy/blob/master/coverage/types.py
Configuration menu - View commit details
-
Copy full SHA for f952e68 - Browse repository at this point
Copy the full SHA f952e68View commit details -
feat(toolchain): Allow to set coverage_tool for a python toolchain
- Only set the tooling if it is actually needed. - By default it is set to None.
Configuration menu - View commit details
-
Copy full SHA for 13b5fe1 - Browse repository at this point
Copy the full SHA 13b5fe1View commit details -
feat(toolchain): allow automatically setting up coverage_tool
The user can turn the coverage_tool setting by passing `register_coverage_tool=(True|False)` to `python_register_toolchains` or `python_register_multi_toolchains` call or specifying the `coverage_tool` label as described in the `versions.bzl` file. Update tests to: - ensure that we can still use the toolchain as previously. - ensure that we are not downloading extra deps if they are not needed.
Configuration menu - View commit details
-
Copy full SHA for f7787d7 - Browse repository at this point
Copy the full SHA f7787d7View commit details -
feat(coverage): use exec_compatible_with
This hopefully makes everything more watertight and will help avoid bugs with misconfiguration.
Configuration menu - View commit details
-
Copy full SHA for 1a5f8cb - Browse repository at this point
Copy the full SHA 1a5f8cbView commit details -
feat(coverage): limit support of coverage to non Windows platforms
It seems that the support is missing upstream [3]. [3]: bazelbuild/bazel#15835
Configuration menu - View commit details
-
Copy full SHA for c2c6ad5 - Browse repository at this point
Copy the full SHA c2c6ad5View commit details -
Configuration menu - View commit details
-
Copy full SHA for c329959 - Browse repository at this point
Copy the full SHA c329959View commit details -
refactor(example/bzlmod): mv __init__.py lib.py
The `__init__.py` files in the root of the WORKSPACE in `bzlmod` is breaking, when running under `bazel coverage //:test`. However, it started working when I renamed `__init__.py` to `lib.py`. I am suspecting that this has to do with the fact that the layer of indirection that `coverage` introduces could be something to do with that.
Configuration menu - View commit details
-
Copy full SHA for 3000ec2 - Browse repository at this point
Copy the full SHA 3000ec2View commit details -
feat(example): coverage config for multi_python_versions
The `multi_python_versions` example cannot show coverage for the more complex tests that are using `subprocess`. I am wondering if this is related to the fact that we are including `coverage.py` via the toolchain and not through other mechanisms [2]. [2]: https://bazel.build/configure/coverage
Configuration menu - View commit details
-
Copy full SHA for 537af93 - Browse repository at this point
Copy the full SHA 537af93View commit details -
Configuration menu - View commit details
-
Copy full SHA for fd1c48f - Browse repository at this point
Copy the full SHA fd1c48fView commit details -
Configuration menu - View commit details
-
Copy full SHA for a6c66dc - Browse repository at this point
Copy the full SHA a6c66dcView commit details -
Configuration menu - View commit details
-
Copy full SHA for 20e62cf - Browse repository at this point
Copy the full SHA 20e62cfView commit details -
Configuration menu - View commit details
-
Copy full SHA for ca97b1d - Browse repository at this point
Copy the full SHA ca97b1dView commit details -
address comment: remove the compatible_with
I am not sure how I can translate the config constraint to a build environment here.
Configuration menu - View commit details
-
Copy full SHA for 52cc5b3 - Browse repository at this point
Copy the full SHA 52cc5b3View commit details -
Configuration menu - View commit details
-
Copy full SHA for d741b92 - Browse repository at this point
Copy the full SHA d741b92View commit details -
address comment: fix a bug in windows handling
The logic should be that we set the `coverage_tool` to None if it is Windows or the tool has been not set.
Configuration menu - View commit details
-
Copy full SHA for 40bd804 - Browse repository at this point
Copy the full SHA 40bd804View commit details -
feat(coverage): Set visibility to the toolchain repo only for non-bzlmod
This changes how we install the coverage dependencies and allows us to set the visibility for the coverage tool correctly by passing the name of the toolchain repo during the repository function execution. bzlmod does not have this due to the fact that the dependency registering is happening in a different way/order.
Configuration menu - View commit details
-
Copy full SHA for 7e48bd6 - Browse repository at this point
Copy the full SHA 7e48bd6View commit details -
fixup: Simplify the supported coverage binary lookup
Now we store everything in a nested dict of tuples, which makes the lookup of supported versions slightly cleaner.
Configuration menu - View commit details
-
Copy full SHA for 4eba78f - Browse repository at this point
Copy the full SHA 4eba78fView commit details -
Configuration menu - View commit details
-
Copy full SHA for 5572799 - Browse repository at this point
Copy the full SHA 5572799View commit details -
Configuration menu - View commit details
-
Copy full SHA for f704efa - Browse repository at this point
Copy the full SHA f704efaView commit details -
Configuration menu - View commit details
-
Copy full SHA for 0af2036 - Browse repository at this point
Copy the full SHA 0af2036View commit details -
Configuration menu - View commit details
-
Copy full SHA for a7bbb2b - Browse repository at this point
Copy the full SHA a7bbb2bView commit details -
Configuration menu - View commit details
-
Copy full SHA for 9628610 - Browse repository at this point
Copy the full SHA 9628610View commit details -
revert: rollback changes to toolchain tests
We rely now on the bazelci config instead
Configuration menu - View commit details
-
Copy full SHA for f02a1b2 - Browse repository at this point
Copy the full SHA f02a1b2View commit details -
Configuration menu - View commit details
-
Copy full SHA for 480ed99 - Browse repository at this point
Copy the full SHA 480ed99View commit details