| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It makes not sense to type `bst fetch --track --deps all <targets>`,
because tracking will inevitably modify the build plan.
Stream initialization will not cope with this either, instead of
silently doing something which does not make any sense, we add an
assertion that this should not happen.
Unfortunately since `plan` is the default deps type for `bst fetch`,
this is likely to happen so it's important to correct.
This patch adds a warning in the case tracking of the build plan
elements is requested, and converts the request to track all elements
instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here the pipeline becomes essentially stateless, some dangling
state remains to be factored out because of frontend accesses
which will be changed in a later commit.
Essentially, the Pipeline.load() method no longer has any knowledge
of the specific purposes of the loaded targets, and now takes
a list of target groups and returns a corresponding list of element
groups.
The Stream() business logic methods now use other pipeline helper
methods to create and filter lists from the loaded target elements.
The Stream() also finally absorbs the Scheduler frontend facing
APIs. However Queues are still exposed on the Stream object for
logging purposes and through callbacks such that the frontend can
retry elements.
|
|
|
|
|
|
|
| |
This removes some additional initialization code from Pipeline().
Some symbols have changed here, the initialization is now called
from Stream(), and a test case was also adjusted for this.
|
|
|
|
| |
There is no more need for this distinction.
|
|
|
|
|
|
|
|
|
| |
This was previously decided in CLI, but knowledge of what to initialize
has been moved to Stream().
Now there is no more point to store this configuration in the Context,
we just have the Stream() decide it when asking the Pipeline() to
invoke the Loader().
|
|
|
|
|
|
| |
This shifts the whole responsibility of interpreting command line
targets etc to the Stream() object itself. With this commit, the
Pipeline() truly becomes slaved to the Stream().
|
|
|
|
|
|
|
|
| |
o This makes logging independent from the Pipeline()
o Removed size_request Widget() method, add context to Widget() initializer
o Make the Status() widget derive anything it needs through the Context()
|
| |
|
|
|
|
| |
Use Stream error for Stream errors.
|
|
|
|
|
|
| |
This is the first part of the pipeline refactor, at this stage
all calling interfaces remain the same, except that invocation
of the scheduler has been moved from Pipline to Stream.
|
|
|
|
|
|
| |
We have machine readable errors for this purpose, and the
strings happen to change causing tests to break if we test the specific
UI (reported error strings are UI).
|
|
|
|
| |
See: #373
|
|
|
|
|
|
|
| |
Lazily parse the version of bwrap the first time the function is called.
On subsequent calls, used cached version info.
See: #373
|
|
|
|
|
| |
"artifacts from all previous stages are passed by default."
https://docs.gitlab.com/ee/ci/yaml/#dependencies
|
|
|
|
|
|
|
|
|
| |
One may want to mount additional volumes to preserve certain directories
or to share some data between the host and the container. Allow users to
do so by providing a `-v` option that passes its arguments to
corresponding `-v`/`--volume` option for `docker run` command.
Part of #378.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the name of the Docker image is hardcoded in bst-here script.
This makes it harder for users to override it, which may be needed for
various reasons (custom plugins, private Docker registries etc.)
Add `-i` option to allow users to specify the base image. When `-i` is
not provided, default to `BST_HERE_IMAGE` environment variable if it's
set and otherwise to the current image -
`buildstream/buildstream-fedora`.
Also, re-order the command-line options in help text and source code in
alphabetical order to maintain sanity as the number of options is slowly
growing.
Part of #378.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
An introduction for this section was also added
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ensure that the strong cache key of each build dependency is available
before an element is built. Otherwise the strong cache key of the
element cannot be calculated and caching the artifact produces an
AssertionError.
In non-strict mode an element's strong cache key may not be available
yet even though an artifact is available in the local cache. This can
happen if the pull job is still pending as the remote cache may have an
artifact that matches the strict cache key, which is preferred over a
locally cached artifact with a weak cache key match.
Fixes #383.
|
|
|
|
|
|
|
| |
changed encode_message push exception from
'Command must by GLib.Variant'
to
'Command must be PushCommand'
|
| |
|
|
|
|
| |
This matches the pull code path.
|
| |
|
|
|
|
| |
Fixes #325.
|
|
|
|
| |
No empty lines after a section title, 2 empty lines before a section title.
|
|
|
|
|
|
|
|
| |
BuildStream
This is rather innacurate, you can build software in any programming languange
given that you have provided the required resources for this in the runtime
you are using.
|
| |
|
|
|
|
| |
As recommended by Valentin David in issue #332.
|
|
|
|
| |
format version 8
|
|
|
|
|
|
|
|
| |
If we want to depend on being able to revision junction.refs and
project.refs separately, then we are better off just considering the
project.refs feature as available since the new version 8.
This will not harm projects which depended on it since version 5 instead.
|
|
|
|
|
|
| |
Leave this error to be handled by preflight.
Updated test case to expect the new ElementError instead of a LoadError
|
|
|
|
|
| |
Move this logic into the junction element itself, instead
of special case erroring for this in the loader.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using setuptools_scm had a couple of bad problems:
o Unexpected versioning semantics, setuptools_scm would
increment the micro version by itself in the case that
we derive a version number from something that is not a tag,
making the assumption that we are "leading up to" the next
micro version.
People mostly dont expect this.
o When installing in developer mode, i.e. with `pip3 install --user -e .`,
then we were always picking the generated version at install time
and never again dynamically resolving it.
Many of our users install this way and update through git, so it's
important that we report more precise versions all the time.
This commit needs to make a series of changes at the same time:
o Adds versioneer.py to the toplevel, this is used by setup.py
for various activities.
This is modified only to inform the linter to skip
o Adds buildstream/_version.py, which is generated by versioneer
and gives us the machinery to automatically derive the correct version
This is modified only to inform the linter to skip
o Adds a .gitattributes file which informs git to substitute
the buildstream/_version.py file, this is just to ensure that
the versioning output would work if ever we used `git archive`
to release a tarball.
o Modifies setup.py and setup.cfg for versioneer
o Modifies utils.py and _frontend/cli.py such as to avoid importing
the derived version when running bash completion mode, we dont
derive the version at completion time because this can result
in running a subprocess (when running in developer install mode)
and is an undesirable overhead.
o Updates tests/frontend/version.py to expect changed version output
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
o _projectrefs.py: Additional constructor option to choose the base name
o _project.py: Load two ProjectRefs objects, one for the junctions
o source.py: Load and save junctioned source refs with the appropriate ProjectRefs object
o tests: Updated some tests to expect junctions to be stored in junction.refs
This fixes issue #361
|
|
|
|
|
|
| |
This is needed so that Sources can derive whether they belong
to a junction or not, which is needed for separating where
junction refs are stored.
|
|
|
|
| |
A late fix for issue #285
|
| |
|
|
|
|
| |
See #431
|
|
|
|
| |
needed
|
|
|
|
| |
See #358
|
|
|
|
| |
See #358
|
| |
|
| |
|