Resolve env variables in bazelrc

[anthpi]

Bazel will now try to resolve environment variables
provided in bazelrc files.
If environmetn variable is not found text will remain
unchanged.

Format to be used: ${FOO}

Example:
import ${GIT_ROOT}/some/path/bazel.rc

[anthpi]

This commit is related to the discussion in #10904

[aiuto]

We never resolve in #10904 if this is a good idea or not.
@lberki I'm passing this off to you to make a judgment call on the feature in general.

[anthpi]

@aiuto I think there are no opinions against the feature (a part from your comment about added complexity). Feature is optional to use and backwards compatible so it should not cause any issues for the existing users.

@lberki For some reason tests on CentOS are still failing and I was not able to identify why. I had similar issues with Windows platform tests and I was able to resolve them by using "blaze::GetEnv()" method that should take care of platform specific implementations. So my guess is that error probably related to the test case rather than to implementation. At the same time CentOS is a Linux platform and I was not able to find any special "ifdefs" that are CentOS specific. I locally run RHEL7 and tests pass. They even pass in Ubuntu environment while being tested by Buildkite. That's why I'm really puzzled about tests failing on CentOS.

@lberki Overall implementation of the feature is not very complex and located in one place. I hope that it should not be hard to maintain it. Feature is backwards compatible and optional to use. It will solve many issues that we have in our environment when we have customers running several workspaces in several repos. In #10904 there were several people mentioning having a bazel wrapper just to be able to achieve same result. Today you either need to have a wrapper or provide parameters on the command line to be able to resolve env variables. Both of those things make environment complex and cumbersome to use for the users. With this feature in place one can remove the unnecessary wrappers and move over many (if not most) of the flags into the .bazelrc file thus greatly simplifying bazel commands that users need to type.

@lberki It's "by design" that format is not platform specific to allow portability between the platforms (if there is such a use case). Also, after discussing internally with my colleagues, we came to a conclusion that keeping values unresolved when required environment variables are not found is probably the best solution because this way users will get a clear error message containing actual name of the environment variable to be able to troubleshoot and fix it. Both of the things are debatable of course and I would like to get your feedback on this. By making these assumptions we were also able to simplify implementation.

[anthpi]

@lberki Did you have time to start looking into this pull request?

[lberki]

Erm, sorry for the delay. I answered on #10904 .

[keertk]

Hi there! Thank you for contributing to the Bazel repository. We appreciate your time and effort. We're doing a clean up of old PRs and will be closing this one since it seems to have stalled. Please feel free to reopen if you’re still interested in pursuing this or if you'd like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.