--workspace_status_command does not compose (or work transparently when building outside the source dir)

[htuch]

The best practice for git build stamping in C++ today is described in #2893. To make this work in a way that is transparent to developers, you provide the workspace status script in a file, e.g. tools/get_workspace_status and place in tools/bazel.rc: build --workspace_status_command=tools/get_workspace_status. That way, most folks who checkout your project from GitHub never need to worry about adding this to the Bazel build command-line.

There's two issues with this:

1. If you perform your build outside the source directory (e.g. let's say the source is in /source and I build in /build via bazel build //... --package_path %workspace%:/source, then Bazel doesn't know where to find tools/get_workspace_status. We hit this in the Envoy CI system where we have this build arrangement, and required symlinks (https://github.com/lyft/envoy/blob/master/ci/build_setup.sh#L86) to make it work. This seems like a hack, there should be a better way. For example, it should be possible to have paths be relative to the source directory somehow, maybe arbitrary Bazel labels.

2. If you have the above arrangement in project A, which gets used as a dependency of project B via git_repository, then project B needs to not only reference project A via git_repository, but somehow:

   1. Know to add to its own tools/bazel.rc a build --workspace_status_command entry.
   2. Know how to find project A on the filesystem to consume its --workspace_status_command at tools/get_workspace_status from A.

Further complicating (2), project B might have its own notion of what constitutes workspace status, which might be completely different to project A. Each project might need some different notion of BUILD_SCM_REVISION to include as a C++ string in its version information.

I think we really need workspace status to not just be a Bazel flag, but a first class property of a project's build system, inside the build rules to solve (2)

@PiotrSikora @mattklein123 @lizan envoyproxy/envoy#415 envoyproxy/envoy#857

[sgowroji]

Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.

[bcsgh]

If this is actually completed, please post a link to the feature that completed it.

If no such feature has been released please update the closed status with something more accurate (e.g. "we think this is a bad idea and won't be implementing it" or "we just blindly closed this without even knowing what was being asked for").

[bcsgh]

BTW: it's very much a hack, but there is a way to get at state like the git HEAD without setting --workspace_status_command:

https://github.com/bcsgh/bazel_rules/blob/master/status_repository/repo.bzl