| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
When stream is asked for a list of artifacts to show for
the purpose of `bst artifact show`, it was squashing the element
name with the artifact name before it gets displayed in the
frontend.
Instead, make the special casing in the frontend.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This behavior has regressed a while back when introducing the messenger
object in 0026e379 from merge request !1500.
Main behavior change:
- Messages in the master log always appear with the task element's
element name and cache key, even if the element or plugin issuing
the log line is not the primary task element.
- Messages logged in the task specific log, retain the context of the
element names and cache keys which are issuing the log lines.
Changes include:
* _message.py: Added the task element name & key members
* _messenger.py: Log the element key as well if it is provided
* _widget.py: Prefer the task name & key when logging, we fallback
to the element name & key in case messages are being logged outside
of any ongoing task (main process/context)
* job.py: Unconditionally stamp messages with the task name & key
Also removed some unused parameters here, clearing up an XXX comment
* plugin.py: Add new `_message_kwargs` instance property, it is the responsibility
of the core base class to maintain the base keyword arguments which
are to be used as kwargs for Message() instances created on behalf
of the issuing plugin.
Use this method to construct messages in Plugin.__message() and to
pass kwargs along to Messenger.timed_activity().
* element.py: Update the `_message_kwargs` when the cache key is updated
* tests/frontend/logging.py: Fix test to expect the cache key in the logline
* tests/frontend/artifact_log.py: Fix test to expect the cache key in the logline
Fixes #1393
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of passing around untyped tuples for cache keys, lets have
a clearly typed object for this.
This makes for more readable code, and additionally corrects the
data model statement of intent that some cache keys should be displayed
as "dim", instead informing the frontend about whether the cache key
is "strict" or not, allowing the frontend to decide how to display
a strict or non-strict key.
This patch does the following:
* types.py: Add _DisplayKey
* element.py: Return a _DisplayKey from Element._get_display_key()
* Other sources: Updated to use the display key object
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a large breaking change, a summary of the changes are that:
* The Scope type is now private, since Element plugins do not have
the choice to view any other scopes.
* Element.dependencies() API change
Now it accepts a "selection" (sequence) of dependency elements, so
that Element.dependencies() can iterate over a collection of dependencies,
ensuring that we iterate over every element only once even when we
need to iterate over multiple element's dependencies.
The old API is moved to Element._dependencies() and still used internally.
* Element.stage_dependency_artifacts() API change
This gets the same treatment as Element.dependencies(), and the old
API is also preserved as Element._stage_dependency_artifacts(), so
that the CLI can stage things for `bst artifact checkout` and such.
* Element.search() API change
The Scope argument is removed, and the old API is preserved as
Element._search() temporarily, until we can remove this completely.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This prepares the ground for policing the dependencies which are visible
to an Element plugin, such that plugins are only allowed to see the
elements in their Scope.BUILD scope, even if they call Element.dependencies()
on a dependency.
This commit does the following:
* Element.dependencies() is now a user facing frontend which yields
ElementProxy elements instead of Elements.
* Various core codepaths have been updated to call the internal
Element._dependencies() codepath which still returns Elements.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This function now prints information about each loaded project in
the session:
* Information about each loaded project
- Junction path, if any
- Provenance of how the project was initially loaded, if any
- Shows which projects declare the loaded project as a duplicate, if any
- Shows which projects declare the loaded project as internal, if any
* Plugins loaded in each project, including how they were loaded
* Project option values resolved for each loaded project
|
| |
|
|
|
|
|
|
| |
Now the PluginFactory.list_plugins() API also reports a human readable
explanation of where the plugin was loaded from for each plugin.
This is internally supported by an extension of the abstract
PluginOrigin.get_plugin_paths() APIs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit makes it mandatory to specify the `plugins` configuration
directly in the `project.conf`, and at the same time removes any ambiguity
as to which plugins are loaded and how. It thus becomes impossible for
the first pass to load the same plugins differently than in the second
pass.
Additionally, some additional project.conf keys are asserted to be
specified in the toplevel project.conf and not included as a matter
of policy and consistency.
Summary of changes:
* _project.py
- Only one set of plugin factories, loaded only in the first pass.
- Assert the following keys are only specified in project.conf and
not included from other files:
name, element-path, min-version, plugins
- The create_element() and create_source() methods no longer need
to take a `first_pass` argument
* element.py: Updated to not specify `first_pass` to create_element()
or create_source()
* _frontend/widget.py: Print the only set of plugins which are loaded,
no more ambiguity about first or second pass.
* _pluginfactory/pluginoriginjunction.py: Chain load plugins from
the single element/source factory, instead of accessing the
Project.config member which no longer has the factories.
|
| |
|
|
| |
An ElementSources object represents the combined sources of an element.
|
| |
|
|
|
| |
Provide context with the element name if an error is raised when trying
to determine element state.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Verifying for variables (all used variables defined and no cycle) is
much faster than flattening them. It also uses much less memory. Only
`bst show -f "%{vars}"` requires to flatten all variables. For other
cases we can improve performance by only checking rather than
flattening.
Also flattening very nested variables could lead to very long lists of
empty strings. The memory usage for flattening could be a lot bigger
than the resulting value. Force flattening and caching every
variable definitions can improve intermediate memory consumption and
only consume memory of the size of the result.
Finally, an optimization allowed inifinite cycles leading to
segmentation fault. This was solved by simplifying the code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This way we split up the logic of how to load plugins from different
origins into their respective classes.
This commit also:
o Introduces PluginType (which is currently either SOURCE or ELEMENT)
o Reduces the complexity of the PluginFactory constructor
o Kills the loaded_dependencies list and the all_loaded_plugins API,
and replaces both of these with a new list_plugins() API.
Consequently the jobpickler.py from the scheduler, and the
widget.py from the frontend, are updated to use list_plugins().
o Split up the PluginOrigin implementations into separate files
Instead of having all PluginOrigin classes in pluginorigin.py, split
it up into one base class and separate files for each implementation,
which is more inline with BuildStream coding style.
This has the unfortunate side effect of adding load_plugin_origin()
into the __init__.py file, because keeping new_from_node() as
a PluginOrigin class method cannot be done without introducing a
cyclic dependency with PluginOrigin and it's implementations.
|
| |
|
|
|
|
|
| |
This replaces the _get_consistency method by two methods:
`_has_all_sources_resolved` and `_has_all_sources_cached` which allows
a more fine grained control on what information is needed.
|
| |
|
|
|
|
| |
'_source_cached' is not explicit enough as it doesn't distinguishes
between sources in their respective caches and sources in the global
sourcecache.
|
| |
|
|
|
| |
Instead output "junction" in magenta for info. Also include test
in format/junctions.py
|
| |
|
|
|
|
|
| |
As discussed over the mailing list, reformat code using Black. This is a
one-off change to reformat all our codebase. Moving forward, we
shouldn't expect such blanket reformats. Rather, we expect each change
to already comply with the Black formatting style.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently we store color configuration in our App object, and have to
remember to pass it around to `click.echo()` when printing things on the
screen. This is error-prone as we can forget to do so. This leads to
bugs like #1200, where `bst init` was not respecting `--no-colors` flag.
Instead of doing that, this patch controls colors in output by
configuring the `click.Context` object.
Fixes #1200.
|
| |
|
|
|
|
|
|
|
| |
--long or -l will provide the user with extra information about the
contents of the artifacts, including permission mode, file type, size
and name. In order for this to work, the way in which list-contents
works has been modified.
A test and NEWS entry have also been added within this commit
|
| |
|
|
|
|
| |
If remotes exist, each remote will be checked for the target
artifacts. If an artifact is cached remotely, we make a
record of this.
|
| |
|
|
|
|
| |
bst artifact show can be used to determine which element names,
artifact refs (also by glob expression) are present within the
artifact cache.
|
| | |
|
| |
|
|
|
|
|
| |
this commit introduces the bst artifact list-contents
command. When used it provides the user with a list of
the contents within the artifact.
Tests and a NEWS entry have also been added for the command.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Adding the element full name and display key into all element related
messages removes the need to look up the plugintable via a plugin
unique_id just to retrieve the same values for logging and widget
frontend display. Relying on plugintable state is also incompatible
if the frontend will be running in a different process, as it will
exist in multiple states.
The element full name is now displayed instead of the unique_id,
such as in the debugging widget. It is also displayed in place of
'name' (i.e including any junction prepend) to be more informative.
|
| |
|
|
|
|
|
|
|
| |
Some call places do not need calls to 'node_sanitize' anymore, therefore
removing the call entirely.
Other still use it for convenience, but that doesn't seem the right way
to do it for consistency. Those places have been replaced by calls to
'Node.strip_node_info()'.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
We only seen to generate the list so we can get its length, so it is
more efficient to only store a count of skipped/processed elements.
failed_elements needs to remain a list for the moment, as it's used to
retry a failed element job.
|
| |
|
|
|
|
|
|
|
| |
Make the signature of LogFile.render() match Widget.render() by making a new
LogFile.render_abbrev() method with the extra functionality. Fix up the
single call site to use that instead.
This means that we won't get linter warnings that helpful inform us that
Widgets are not really substitutable.
|
| |
|
|
|
|
|
|
|
|
| |
For most use-cases with modern Python, it's not necessary to supply the
'type' or 'object-or-type' arguments to super().
Replace all our instances with arg-less super, which is less
error-prone.
https://docs.python.org/3.5/library/functions.html#super
|
|
|
This was discussed in #1008.
Fixes #1009.
|
