| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
| |
And adding --integrate/--no-integrate option to `bst checkout`
|
| |
|
|
|
| |
Also now the integration option to `bst checkout` is explicit,
as we dont have knowledge of arches anymore.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This makes buildstream behave the same way with tarballs which
were encoded with a leading `.` and those encoded without one.
This fixes issue #145
|
| |
|
|
|
|
| |
Now test to also ensure that base-dir expressions always behave
the same way regardless of whether the tarball was created with
a leading '.' or not.
|
| | |
|
| |
|
|
| |
This is equivalent to the tar source, but for Zip archives.
|
| |
|
|
|
|
|
|
|
|
|
| |
The new DownloadableFileSource will be used as a base for all sources
which just download a file to use as source.
The existing TarSource just keeps the code responsible to manage a Tar
archive.
This will help implemeting other types of single file downloaded
sources, for example Zip archives.
|
| |
|
|
|
| |
The utility function was added in 08da7cc7, but it never was removed
from here.
|
| |
|
|
|
|
| |
This test was encoding tarballs with '.', so the change of
ignoring '.' breaks this - now we just make the tar test
scaffolding use an empty string for the base-dir.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To extract the full tarball, one should set base-dir to an
empty string.
By ignoring the leading '.' in any archive, we make the 'base-dir'
API more predictable and reliable - the default behavior of '*' is
to pickup the first directory in the tarball (usually source code
tarballs are encoded with one leading directory) - in the off chance
that a source tarball has a leading '.' in it; that would cause
the 'base-dir' default '*' glob to extract the whole thing.
It seems undesirable to behave differently depending on whether
a tarball was encoded with, or without a leading '.'
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is used by the platform to disable pushing explicitly in
the case that we're falling back to not using user namespaces, in
which case we dont entirely trust the artifacts we create.
|
| |
|
|
| |
Part of the fix for #92
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Here we check if `bwrap --ro-bind / / --unshare-user --uid 0 --gid 0 whoami`
returns successfully and prints 'root', to check if we are indeed capable
of creating user namespaces on the host.
If we are unable, then we save that state in the platform allowing
buildstream to behave differently, and print an informative startup
warning about this.
This fixes issue #92
|
| |
|
|
|
| |
Dont use the plugin which the message originates from, use the
plugin associated with the child task.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
We avoid printing regular start/success/status messages etc
at startup time in advance of the heading, this would introduce
a lot of noise while interrogating source plugins for consistency
state.
This patch holds on to important errors and warnings which might
be raised by core components at startup time, and prints them
immediately after printing the heading.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Attempting to compose a list property would result in an unhandled
exception:
AttributeError: 'CommentedSeq' object has no attribute 'get'
We now at least detect the situation and produce an exception that
the frontend will report neatly:
Error loading pipeline: element.bst [line 11 column 4]: Only values of type 'dict' can be composed.
I was getting this error from an attempt to conditionally extend the
sources list:
sources:
(?):
arch == "x86_64":
- url: http://example.com/x86_64
The correct way to do this is to move the conditional into the parent
dict, e.g.:
(?):
arch == "x86_64":
sources:
- url: https://example.com/x86_64
It would be nice if the error message could hint at how the user can do
what they want, but it doesn't seem possible in this case.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Profiling suggested that the cumulative time spent in os.path.relpath()
was the dominant cost of utils.list_relative_paths().
Try to call this only once per directory walked.
In Python 3.5, we can optimise further by using os.scandir() and
maintaining relative paths as we go.
|
| |
|
|
|
|
|
| |
This is deadcode, except_ is already calculated before we get here.
Updated some internal comments to reflect this, and updated the frontend
to not pass the useless except_ parameter.
|
| |
|
|
|
| |
These come exclusively from the frontend or _pipeline.py code, we just
avoid printing an element name or cache key for these messages.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, use None as the unique ID.
This will help with messaging when we allow invoking multiple targets
and the element would have been ambiguous - this also consequently
fixes issue #137.
The reason for the hangs with #137 is because:
o When you --except a base element, reverse dependencies cannot calculate a cache key
o When you track, cache keys are intentionally reset at startup time, because
we know they are going to change
o At the end of tracking, we make one attempt to print the toplevel cache key
This operation is insanely expensive, because we never cache a cache key because
it logically cannot ever be resolved in this situation.
This fix is basically a workaround to the above.
|
| | |
|
| |
|
|
|
|
|
|
| |
This wont take any additional time because if there is
a remote artifact share configured in the pytest suite, it
can only be a locally created one - this makes the push/pull
tests work after recently making downloading of remote refs
optional for the sake of issue #140.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
o bst build
o bst push
o bst pull
o bst show --downloadable
This adds a `--downloadable` option to `bst show`, if this is
specified then buildstream will spend some time trying to download
the remote artifact share's refs and refresh the local downloadable
state.
This fixes #140
|
| |
|
|
| |
Default is not to fetch them, we only need them in a few cases.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
It has been moved to an external repository.
|
| | |
|
| |
|
|
| |
This is an interim step for issue #131.
|
| |
|
|
|
|
| |
First case simply asserts that prepending to configure-commands
from the project.conf works as intended, ensuring we dont regress
issue #127
|
| |
|
|
|
|
|
|
|
|
|
| |
The element overrides are intended for later recomposition onto
the element type specific yaml files, so it is incorrect to assert
that array composition is complete at this stage.
Instead remove the element overrides and store those seperately
before making our final yaml assertions.
This fixes issue #127
|
| |
|
|
|
|
|
|
|
|
| |
I was seeing messages like this:
Fetching artifact list from None
However, the artifact cache did have the correct pull URL set -- the
issue was that I had overridden it my own config, and the string we
sent to the ticker didn't take that override into account.
|
| | |
|
| |
|
|
| |
And also ensure that expression errors are reported with provenance.
|
| |
|
|
|
| |
When using an undefined option in a conditional expression, buildstream
should error out and print a good message about it.
|
| | |
|
