-
Notifications
You must be signed in to change notification settings - Fork 91
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
Expand "Make" variables inside of values in the env dictionary on test rules #3088
Expand "Make" variables inside of values in the env dictionary on test rules #3088
Conversation
I'm fine with bumping our minimum required version of rules_apple to 3.6.0. I agree there is no good way to detect this otherwise. Though, we could add a flag to go back to the old behavior? I would rather just bump our dep though.
I don't think there is a better way? |
I've increasingly come to regret the way I introduced support for this feature in rules_apple. I think the most flexible behavior from a UX standpoint is a way to map Bazel settings to project-level xcconfigs, so they're available to the scheme without having to regenerate them, but then you'd need to regenerate the xcconfig instead. I can put up a new commit that bumps the minimum rules_apple to 3.6.0. Thank you for taking a look at this draft. |
Any progress on this? We encounter exactly the same problem. |
e934fba
to
26b2a71
Compare
…t rules Signed-off-by: Aaron Sky <aaronsky@skyaaron.com>
26b2a71
to
62364ab
Compare
@brentleyjones anything else we need to do to get this landed? |
I would like another review. |
@congt would y'all be able to test this change in Square and see if it fixes the issue |
Just verified it works for us |
Thanks everyone! |
Fixes #3056
This PR implements a gap introduced when bazelbuild/rules_apple#2476 was introduced, where expandable env settings on test rules would not be expanded into the xcscheme during generation. There are a couple of things that reviewers should be aware of before proceeding with this change: