| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
This will need more attention when we bring in another virtual
directory backend, however, we've said it is acceptable for the
sandbox itself to access the underlying directory, and this is
the best fix in the meantime.
|
| |
|
|
|
|
|
|
|
|
| |
This is to allow to allow its use by subclasses.
Since access to get_directories is now blocked for some plugins,
and the subclasses of Sandbox do not have configuration defined
by YAML files, they need another way to get at the root directory.
|
| |
|
|
|
|
|
|
|
| |
Before running a command in the sandbox, check its existence and fail
early if it does not.
This fixes issue #289.
|
|
|
|
| |
Fixes #424
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This only affects SandboxBWrap at the moment.
buildstream/_loader.py: Add Symbol.SANDBOX and allow it in validation
buildstream/_metaelement.py: Add 'sandbox' variable and store it in the object
buildstream/_project.py: Add 'sandbox' configuration key and load it from
project.conf.
buildstream/data/projectconfig.yaml: Default build-uid/build-gid values of 0
for 'sandbox'.
buildstream/element.py: Add __extract_sandbox_config to find the final sandbox
configuration. Pass this to the sandbox constructor.
buildstream/sandbox/_sandboxbwrap.py: If sandbox configuration was supplied,
use it for uid and gid instead of the default 0.
buildstream/sandbox/_sandboxchroot.py: Throw exception if non-0 uid/gid were
supplied.
buildstream/sandbox/__init__.py: Import SandboxConfig.
buildstream/sandbox/_private.py: New file, containing SandboxConfig. Made private
to avoid documentation for this class.
|
| |
|
|
|
|
|
|
| |
This allows D-Bus access.
Fixes #227
|
|
|
|
|
| |
This attempts to document and specify our current sandboxing
functionality.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This functionality is only supported for sources which have an open
workspace. When such sources are present, the workspace directory will
be mounted directly inside the sandbox. As opposed to the default
behavior, which is to copy files inside the sandbox.
This will save time when building large projects as only those files
will need be re-compiled that have been modified during two consecutive
builds (assuming the underlying build system supports such behavior).
A few things to note regarding this behavior:
- If there are any `configure-commands` present, they will run only once
for each open workspace. If an element has multiple workspaces and any
one of them is opened/closed, they will be executed again on the next
run. But, modifying the contents of a workspace will not trigger the
`configure-commands` to be executed on the next run.
- Workspaced builds still leverage the cache. So, if no changes are made
to the workspace, i.e. no files are modified, then it will not force a
rebuild.
Fixes #192.
|
| |
|
| |
|
| |
|
|
|
|
| |
Hide all of buildstream's internal exceptions from the API surface.
|
| |
|
| |
|
|
|