Skip to content

Return TemplateVariableInfo#1412

Closed
uhthomas wants to merge 1 commit intobazelbuild:mainfrom
uhthomas:1377-2
Closed

Return TemplateVariableInfo#1412
uhthomas wants to merge 1 commit intobazelbuild:mainfrom
uhthomas:1377-2

Conversation

@uhthomas
Copy link
Copy Markdown
Contributor

@uhthomas uhthomas commented Jun 14, 2022

Copy link
Copy Markdown
Collaborator

@UebelAndre UebelAndre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a test, demonstrating how the TemplateVariableInfo would be consumed?

Additionally, would you be able to move the str(Label()) stuff into a separate PR so the required changes to the toolchain for the new functionality is clearer?

@uhthomas
Copy link
Copy Markdown
Contributor Author

Can you add a test, demonstrating how the TemplateVariableInfo would be consumed?

Additionally, would you be able to move the str(Label()) stuff into a separate PR so the required changes to the toolchain for the new functionality is clearer?

Happy to do those things, will update shortly.

@uhthomas uhthomas force-pushed the 1377-2 branch 2 times, most recently from 4a34748 to 25b7b6f Compare June 14, 2022 21:52
@uhthomas
Copy link
Copy Markdown
Contributor Author

@UebelAndre I've removed the str(Label()) stuff and added a test. Would you be able to take a look?

@uhthomas uhthomas force-pushed the 1377-2 branch 3 times, most recently from e81c828 to 4ff6367 Compare June 14, 2022 22:28
Copy link
Copy Markdown
Collaborator

@UebelAndre UebelAndre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I love all the cleanup but could the provider defnitions (with the exception of rust_toolchain) also be moved to a separate PR? To keep the implementation of TemplateVariableInfo as concise as possible?

Comment thread .bazelci/presubmit.yml Outdated
name: Rust TemplateVariableInfo Tests
platform: ubuntu2004
test_targets:
- "//test/rust_toolchain_template_variable_info:rust_toolchain_template_info_test"
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't this test be picked up by existing jobs?

@@ -0,0 +1,26 @@
"""A module which defines rules for testing TemplateVariableInfo"""
Copy link
Copy Markdown
Collaborator

@UebelAndre UebelAndre Jun 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's already similar tests in //test/unit/toolchain_make_variables/toolchain_make_variables_test.bzl, could you instead expand the pattern there (specifically just using the starlark unittest framework) to cover the new cases?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yes. Will merge them. Thanks!

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only trouble is bazelbuild/bazel-skylib#375 sort of blocks it.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you need to write a rule that consumes the toolchain? Is the target you wrote for the test the thing you want to do? Have some target with:

env = {
    "CARGO": "$(CARGO)",
    "RUSTC": "$(RUSTC)",
}

That should be testable in a similar way to the current tests. You're not transitioning these targets so couldn't you also use current_rust_toolchain to find values to match against if you wanted to test environment variables for the action?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If a unit test is hard because of issues in skylib, let's just use an integration test?

I filed uhthomas#1 with an example - WDYT?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even better, some usages of "$(rootpath @rules_rust//rust/toolchain:current_cargo_files)" should be replaced with the template variable info.

https://cs.github.com/bazelbuild/rules_rust?q=%22%24%28rootpath+%40rules_rust%2F%2Frust%2Ftoolchain%3Acurrent_cargo_files%29%22

"CARGO": "$(rootpath @rules_rust//rust/toolchain:current_cargo_files)",

"CARGO": "$(rootpath @rules_rust//rust/toolchain:current_cargo_files)",

"CARGO": "$(rootpath @rules_rust//rust/toolchain:current_cargo_files)",

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#1412 (comment) I think this should be a separate PR but sounds reasonable.

@uhthomas Can you take another look? I've updated the tests.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No? It outputs a path just fine, though the path seems to be different?

In test _rust_toolchain_make_variable_expansion_test from //test/unit/toolchain_make_variables:toolchain_make_variables_test.bzl: Expected env[ENV_VAR_CARGO] to be equal to 'bazel-out/k8-fastbuild/bin/external/rust_linux_x86_64/toolchain_for_x86_64-unknown-linux-gnu_impl/bin/cargo', got 'bazel-out/host/bin/external/rust_linux_x86_64/toolchain_for_x86_64-unknown-linux-gnu_impl/bin/cargo'
-bazel-out/k8-fastbuild/bin/external/rust_linux_x86_64/toolchain_for_x86_64-unknown-linux-gnu_impl/bin/cargo|
+bazel-out/host/bin/external/rust_linux_x86_64/toolchain_for_x86_64-unknown-linux-gnu_impl/bin/cargo

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this something you'd be able to pickup and find a solution for? It's also odd to me that the tests passed on all other jobs but not the Min Bazel Version ones

Comment thread rust/toolchain.bzl
@uhthomas uhthomas changed the title Return TemplateVariableInfo, explicitly declare provides and providers Return TemplateVariableInfo Jun 15, 2022
@@ -0,0 +1,26 @@
"""A module which defines rules for testing TemplateVariableInfo"""
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you need to write a rule that consumes the toolchain? Is the target you wrote for the test the thing you want to do? Have some target with:

env = {
    "CARGO": "$(CARGO)",
    "RUSTC": "$(RUSTC)",
}

That should be testable in a similar way to the current tests. You're not transitioning these targets so couldn't you also use current_rust_toolchain to find values to match against if you wanted to test environment variables for the action?

@UebelAndre UebelAndre requested a review from illicitonion June 15, 2022 03:38
@UebelAndre
Copy link
Copy Markdown
Collaborator

@illicitonion may have some good insight here.

@UebelAndre
Copy link
Copy Markdown
Collaborator

I think all the implementation here was merged in #1416. If there's anything I missed on that PR I'm happy to review another, but hopefully you have the features you were hoping to get now 😄

@uhthomas
Copy link
Copy Markdown
Contributor Author

uhthomas commented Jul 1, 2022

Amazing! Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants