gtristan commented on code in PR #2036:
URL: https://github.com/apache/buildstream/pull/2036#discussion_r2241778060
##########
src/buildstream/buildelement.py:
##########
@@ -285,10 +305,20 @@ def configure_sandbox(self, sandbox):
command_dir = build_root
sandbox.set_work_directory(command_dir)
- # Setup environment
- sandbox.set_environment(self.get_environment())
-
def stage(self, sandbox):
+ # Setup environment
Review Comment:
> However, even if that works, there is still one potential issue, which is
that this would not guarantee that the directory tree referenced by the digest
environment variable is available in the local cache, as the artifact doesn't
reference that digest (except via that environment variable but BuildStream
core is not aware of that). Maybe we can add that to the Artifact proto as
well, but this may require additional code and API in the core for use by
BuildElement. Or do you have another suggestion?
We are interestingly dancing on the line of sanity here.
* The assumption with `bst shell --build --use-buildtree` is that you have
everything you need to reproduce the (probably failed) build locally in order
to debug it.
* The assumption with exporting the local casd socket to the build
environment, and moreso, remoting out the builds to a different sandbox
(whether it is on the same machine or not)... is that you have your hands on
some sensitive things, you know what you are doing, and you risk corrupting
your build and cache with some non-determinism
The above two are not necessarily at odds with eachother, but it could be
fair to say that if you are doing this wild stuff, you are out of bounds for
having support for debugging remotely failed builds.
I think that I would be satisfied with either of the following:
* The officially supported and documented usage of `recc` is to use it
locally in your sandbox, exercise the local compiler in the same sandbox, and
use only the caching nature of `recc` to store/lookup objects in the CAS
* This would "just work" given that we use the same environment variables
from cached artifacts
* The officially supported and documented usage of `recc` is to selectively
stage the compiler, source code and required header files to an adjacent
sandbox on the same buildhost via the local `buildbox-casd` feature, and the
artifact proto is extended to capture a list of digests which might be used for
weird features like this one
I.e., lets support something, and if you are doing something outside of what
is supported, you might be on your own and your build shells for debugging
remotely failed artifacts might not work.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
