Repository navigation
fix: don't materialize rules_python when reading the artifacts manifest #4370
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,16 @@ | ||
| """Manifest of prebuilt tool binaries. | ||
|
|
||
| Empty in git, so source checkouts build the tools from source. The release | ||
| process replaces this file in the release archive with one whose | ||
| `ARTIFACTS_MANIFEST_JSON` holds the JSON manifest of the release's binaries. | ||
|
|
||
| It's a .bzl file so the `config` extension can load it rather than read it by | ||
| Label, which would make Bazel's remote repository contents cache materialize | ||
| the entire repository. Once https://github.com/bazelbuild/bazel/pull/31493 | ||
| lands, reading by Label no longer materializes, and this can go back to being | ||
| a plain JSON file. | ||
| """ | ||
|
|
||
| # A JSON string rather than Starlark values, so the builtin manifest is parsed | ||
| # by the same code path as a custom prebuilt tools manifest. | ||
| ARTIFACTS_MANIFEST_JSON = "" | ||
This file was deleted.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -125,20 +125,14 @@ def _test_configure_tool_toolchains_from_source(name): | |
| ) | ||
|
|
||
| def _test_configure_tool_toolchains_from_source_impl(env): | ||
| manifest_label = str(Label("//python/private:artifacts_manifest.json")) | ||
| http_file = mocks.repo() | ||
| toolchain_repo = mocks.repo() | ||
| tools_toolchains_repo = mocks.repo() | ||
| mctx = mocks.mctx( | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should add a validation or a comment here to ensure that we don't do something similar in the future. Could we in theory add an integration test to test a regression like this?
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. With the mocks, it might not be so bad to do that. All the the mctx.read() calls should go through the mock interface, so if that kept track of the paths it saw, you could then compute if the read would have caused a repo to be materialized. For an integration test, not sure, since it requires the remote repo cache. It sounded like @sputt had a cleaner repro strategy, so maybe they have ideas / know
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The mock path is a good first step, I think. The reads would use a label and we can probably easilly detect it. |
||
| mock_files = { | ||
| manifest_label: "# Stub manifest with only comments.\n# Another comment.\n\n", | ||
| }, | ||
| ) | ||
| configure_tool_toolchains( | ||
| mctx, | ||
| http_file = http_file.rule, | ||
| prebuilt_exe_zip_maker_toolchain_impl_repo = toolchain_repo.rule, | ||
| tools_toolchains_repo = tools_toolchains_repo.rule, | ||
| artifacts_manifest_json = "\n", | ||
| ) | ||
| env.expect.that_collection(http_file.calls).contains_exactly([]) | ||
| env.expect.that_collection(toolchain_repo.calls).contains_exactly([]) | ||
|
|
@@ -164,7 +158,6 @@ def _test_configure_tool_toolchains_prebuilt(name): | |
| ) | ||
|
|
||
| def _test_configure_tool_toolchains_prebuilt_impl(env): | ||
| manifest_label = str(Label("//python/private:artifacts_manifest.json")) | ||
| manifest_json = json.encode({ | ||
| "artifacts": { | ||
| "exe_zip_maker": [ | ||
|
|
@@ -192,12 +185,11 @@ def _test_configure_tool_toolchains_prebuilt_impl(env): | |
| http_file = mocks.repo() | ||
| toolchain_repo = mocks.repo() | ||
| tools_toolchains_repo = mocks.repo() | ||
| mctx = mocks.mctx(mock_files = {manifest_label: manifest_json}) | ||
| configure_tool_toolchains( | ||
| mctx, | ||
| http_file = http_file.rule, | ||
| prebuilt_exe_zip_maker_toolchain_impl_repo = toolchain_repo.rule, | ||
| tools_toolchains_repo = tools_toolchains_repo.rule, | ||
| artifacts_manifest_json = manifest_json, | ||
| ) | ||
| env.expect.that_collection(http_file.calls).contains_exactly([ | ||
| { | ||
|
|
||
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.
An embedded JSON string is a bit weird, so add a comment about why we do that: to keep the code paths for loading a custom prebuilt tools manifest the same as when using the builtin manifest.