Workspace builds are unable to preserve intermediate results not stored in the source directory.
Summary
It's not unusual to have projects whose build system stores their intermediate results in a different directory to the source directory. e.g. have a C project put its object files in a directory called ../o
relative to the source directory.
directory
may be used to stage into a relative sub-directory and leave space to have an objects directory, but since workspace builds just bind-mount the source directory into the sandbox, object files outside of the sandbox are not preserved.
Steps to reproduce
What is the current bug behavior?
Contrary to the expectation of workspace builds preserving intermediate files, only intermediate files in the source directory are preserved.
What is the expected correct behavior?
Intermediate files from previous builds of that workspace are available in the sandbox to be reused by the build.
Possible fixes
-
If the element's source layout matches the workspace's layout, bind-mount a parent directory, rather than the source itself, into the sandbox.
Probably not a useful solution since it requires the user to change how they arrange their workspace to support it.
-
Add a new workspace command or a new option to
workspace open
to link a directory to be bind-mounted in with the source directory. -
Store those intermediate objects in artifacts in the cache and stage them in addition to mounting the workspace's source directory.
Caching and staging the intermediate files appeals from a cleanliness POV, but is a big difference in behaviour from how workspaces normally work, since it's expected that the intermediate files are around to inspect.
There were also suggestions that it was wanted that these intermediate files may appear anywhere on the filesystem rather than alongside the source directory, which may require a filesystem watcher or overlayfs to handle efficiently.