| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
When code is faulty, in a plugin or in the core, we should
get a stack trace and a BUG message.
|
|
|
|
|
|
|
|
|
|
| |
Since we added batch commands, the batch commands print the
text of the commands directly in the message text, but this is wrong.
The detail string is the appropriate place for text of unknown lengths
(the user can actually configure how many max lines of commands they
want to see in their log), the message text itself should be controlled
and brief enough to avoid text wrapping.
|
|
|
|
| |
Fixes issue #740
|
|
|
|
| |
This adds the batch() context manager.
|
|
|
|
| |
This improves readability.
|
| |
|
|
|
|
|
| |
The Context was only used to obtain a reference to the CASCache
and set the unused cas_directory field.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
i.e. instead of taking a directory that must contain "root" and
"scratch", and treating "root" as the root, use the directory directly.
In element.py:
* __sandbox takes the `bare_sandbox` arg, to pass into the sandbox's constructor
In sandbox.py:
* If bare_sandbox, `_root` is the passed-in directory, and `__scratch`
is None.
* Trying to use `__scratch` when bare_sandbox is True is a bug.
In _mount.py:
* Don't get the value of `__scratch` if it's not needed.
This is part of #539
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code was creating the cwd folder but when the workspace was
mounted in to the buildroot it was hiding the folder created in it
behind the bind mounted workspace.
However by using the bubblewarp `--dir` directive to ensure that cwd
exists we can cover both workspace and non workspace situations with
the same method.
For issue #512 in Gitlab.
|
|
|
|
|
| |
Also update the documentation for get_virtual_directory to make the
implications of using both methods clearer.
|
| |
|
|
|
|
|
|
|
|
| |
This is for use after remote execution has finished, since remote
execution produces a new output directory rather than modifying
the initial directory.
https://gitlab.com/BuildStream/buildstream/issues/454
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|