| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
o Testing that we can load a custom element or source
o Testing that we assert and trigger an error when the requested
format version of a plugin by the project is greater than the
reported version of the plugin
|
| |
|
|
|
|
|
|
|
|
| |
Plugins can now advertize their respective format version with
this class attribute.
At instantiation time, the plugin will take care of asserting
that the project's versioning requirements are met.
|
|
|
|
|
|
|
|
|
| |
o Define the base buildstream format as BST_FORMAT_VERSION
in the project module
o Load and cache any required versions of plugins
o Assert overall project version is supported at load time
|
| |
|
|
|
|
|
|
| |
Instead use BST_STRICT_REBUILD and follow a new pattern we're
using for any class attributes used for the plugin to communicate
static data back to the core.
|
|
|
|
|
|
|
|
|
|
|
| |
Starting to go with using class attributes in some
cases for the plugin to communicate static things
like required version and strict rebuild policies.
This is interesting because class attributes suggest
that you cannot return something dynamic, and at the
same time class attributes are useful at times when
you have a plugin type but no instance.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added assertions:
o Bail out with a PluginError instead of an ImportError in
the case that PluginSource.load_plugin() fails to import
the plugin.
o Assert that the running buildstream version is new enough
for any loaded plugin, otherwise bail out with a
PluginError.
Also changed all string formatting here to be consistent
with the rest of buildstream and use "{}".format("foo") instead
of "%s" % "foo".
|
|
|
|
|
| |
Element and Source plugins can set this as class data to indicate the
minimal BuildStream API they depend on.
|
|
|
|
| |
Fetches the numeric major/minor version of the BuildStream package.
|
|
|
|
|
| |
Errors which were previously detected when loading the
plugin context are now only detected when loading the plugin.
|
|
|
|
| |
This fixes issue #79
|
|
|
|
|
|
|
|
| |
Using the new enhanced Element API for staging, allow the
user to specify domains to exclude as well as domains to
include.
Fixes issue #78
|
|
|
|
|
|
|
|
|
| |
Instead of just being able to specify what domains to include and
whether to include orphans, also specify what domains to exclude.
This allows one to deal with situations with overlapping rules
more dynamically; i.e. one can include all of `/usr/bin/*` and
then specifically exclude `/usr/bin/gcc` by itself.
|
|
|
|
|
|
|
|
| |
Allows for more information in timed activities, consequently
avoiding the need for additional status messages in some cases.
The message detail component is only shown at activity START time
but omitted at FAILURE/SUCCESS time.
|
|
|
|
|
|
|
|
|
|
|
| |
The click completions code was written based on my branch
of click master, which I had been running locally.
Yesterday it worked but only against master, this patch
adds some extra customizations so that we can handle specific
arguments (like bst file targets) specially, and now it works
with stable releases of click, which means buildstream is
no longer broken also.
|
| |
|
|
|
|
|
| |
Currently this gets installed at ${prefix}/share/bash-completion/completions
but this is not exactly correct.
|
|
|
|
|
|
| |
Just override clicks main entry point at just the right
time to step in and do our completions before it gets
a chance.
|
|
|
|
|
| |
Now we complete bst files in the project's element directory
when completions are available.
|
|
|
|
|
|
|
|
|
| |
This is based on my branch of the click library where I was
unable to land a patch for this.
We should use an upstream solution once this issue is solved:
https://github.com/pallets/click/issues/780
|
|
|
|
| |
Fixes #59
|
|
|
|
| |
Fixes issue #66
|
|
|
|
| |
Fixes #65
|
|
|
|
| |
If specified, the command will run in non-interactive mode.
|
|
|
|
|
|
|
|
|
|
|
|
| |
`bst workspace {open,close,reset} <bst> --source <index>` commands currently
give an indexing error. The python click library needs to be told that the
expected argument is of type integer.
This patch also makes use of metavar to display a placeholder in the help
prompt, like:
-s, --source INDEX The source to create a workspace for. Projects with one
source may omit this
|
|
|
|
|
|
|
|
|
|
| |
Remove the requirement to specify '--force' in conjunction with
'--no-checkout' if there are already files in the workspace. We won't
write anything when opening the workspace, so there's nothing to force.
For example, when opening a workspace to an existing clone of a
repository, it seems alarming to have to '--force' the workspace open.
It made me wonder if it will actually be overwritten.
|
|
|
|
| |
Fixes #60
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Packaging is a big topic in the Python community these days. Things are
evolving, but a consensus seems to have formed around the path forward.
With PEP 518, Pip is becoming the primary tool to install Python
modules. In turn, Pip will use the right underlying tool for the job.
(distutils, setuptools, flint, ...)
Given all this, it makes sense to have a pip element in BuildStream.
This element installs a single Python module, telling Pip not to go and
download its dependencies, to make builds reproducible and not rely
on the network during builds.
By default it will use the `pip` command which generally points to Pip
for Python 2. Users can override the "pip" variable, for example to use
the `pip3` command, which generally points to Pip for Python 3.
|
|
|
|
| |
This seems to be a simple copy-paste mistake.
|
|
|
|
|
|
|
|
| |
To build all elements, the source bundle has to include the sources and
scripts for all elements, not just build dependencies and their runtime
dependencies.
This removes the --deps option as it doesn't make sense in this context.
|
|
|
|
| |
Fixes #57
|
| |
|
|
|
|
| |
Fixes #58
|
| |
|
|
|
|
|
|
| |
This is equivalent to not specifying a dependency type at all.
Fixes #61
|
| |
|
|
|
|
|
|
|
| |
This is mainly useful for testing artifact caches and such. Most users
will hopefully be able to make use of artifact caches populated by
automated build machines, but right now it's unlikely that most people
will be pushing artifacts around.
|
|
|
|
| |
This is required when using a push queue without build queue.
|
| |
|
|
|
|
| |
Strong ref was not created.
|
|
|
|
| |
Not useful for builds, but interesting for network related tasks.
|
| |
|
| |
|
|
|
|
|
|
|
| |
(strict_rebuild)
This was doing a non-recursive calculation of weak cache keys, but the intention
was to do a recursive one; this is why my demo was an epic failure.
|
| |
|
| |
|