| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Users shouldn't see any difference between values hardcoded in Python (if
there are any) and the values in projectconfig.yaml, which were previously
items 0 and 1 respectively. Combined these both into 1 and made it clear that
not all of project.conf is applied right away.
|
|
|
|
|
|
|
|
| |
version 1
This was added slightly before format version 1, but was done
without a version increment. Previous format versions cannot
be relied upon for use of this feature.
|
|
|
|
|
| |
This is made redundant by the more complete `environment` configuration,
so lets quickly remove the former in this new format version 4.
|
|
|
|
|
|
|
| |
And also ammend the documentation for `host-files` to note that
the paths support host side environment variable expansion.
Documenting both `host-files` and `environment` to require format version 4.
|
|
|
|
| |
This is now enhanced and an API change was introduced.
|
| |
|
| |
|
|
|
|
|
|
| |
The junction attribute was merged fairly recently in the 1.1 series without
bumping the project format version, this documents the junctions addition
to be added since the closest version bump where support exists.
|
| |
|
|
|
|
|
|
| |
This is not a part of the documentation on how external plugins
are loaded and referenced; lets put it in the main general section
instead.
|
|
|
|
|
| |
This attempts to document and specify our current sandboxing
functionality.
|
|
|
|
|
|
|
|
| |
It previously neglected to describe how sources were composed, and we've
changed how sources are composed, recently.
In addition, it was slightly confusing to have the project conf be the
title of two different stages of composition.
|
|
|
|
|
| |
Equivalent to the 'elements' field, but slightly different because
sources don't have accompanying yaml.
|
|
|
|
|
|
|
| |
Reword 'Flags type options' slightly for more clarity.
We use 'option type' to refer to these thingies elsewhere, adjust
'arch' to be the same way.
|
|
|
|
|
| |
This introduces junctions as a new kind of elements to allow
dependencies to cross project boundaries.
|
|
|
|
|
|
| |
This was pushed accidentally.
This reverts commit 34a60189be63dc86d333ca895ce44bd24adb43c3.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is intended to make things easier to find for the
various types of people searching for stuff.
o The installation instructions remain on the main page.
o Three main separate pages have been created
- Using BuildStream
- Authoring BuildStream projects
- Core API reference, for plugin authors
o The "Authoring projects" section swallows the
previous plugin index; so one can find the plugin one
is looking for on the same page as the rest of the format
docs
o The plugin authoring section has been swallowed by the
core API reference section, with a note that this is useful
especially for plugin authors.
|
| |
|
| |
|
|
|
|
| |
libfuse
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes issue #183.
Also move the `format-version` related documentation to the first
section "Essentials", beside the project name and element path, since
this is a quite global option it belongs here and not hidden away
with the plugin loading documentation.
Also adjust the main index.rst to include the plugins sub-section
as an adjacent sub-point of the project configuration (consistent
with other project configuration sections).
|
|
|
|
|
| |
It's more suitable to add this note here than to have a separate section
in the HACKING.rst for this.
|
| |
|
|
|
|
|
| |
Instead add a comment about why this is really there,
and invoke sphinx python modules with python3 directly.
|
|
|
|
|
|
|
|
|
|
| |
Some of the warnings from sphinx-build are really just warnings,
but a lot of the things we want to avoid and really break documentation,
like broken internal references and some invalid rst directives should
really be errors.
Now we treat all warnings as errors, this should ensure that
any commits landing upstream never break the docs.
|
|
|
|
|
|
| |
Fixes the warning:
WARNING: /path/to/buildstream/doc/source/install.rst:45: (WARNING/2) Title underline too short.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
In addition, it changes the "plugins" and "required-versions" fields,
combining them for plugins and adding a new "required-project-version"
field.
|
| |
|
|
|
|
|
|
|
|
| |
This is possible now that the SSH protocol can redirect to the
appropriate pull URL.
Note that this commit makes no attempt at backwards compatibility.
Everthing will break!
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ports can and should be specified by using proper ssh:// URL forms,
e.g:
ssh://artifacts@example.com:22200/artifacts
The alternate form of artifacts@example.com:artifacts isn't a valid
URL, and doesn't let you specify a different port. People are used
to this form due to Git continuing to use it but we should encourage
people to use proper URLs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is part of issue #112 ("Artifact configuration is confusing
and fragile, need canonical push/pull urls.")
It updates the bst-artifact-receive program to send a pull URL to
clients who access it over SSH.
This requires extra configuration in the artifact cache server, so that
it knows the correct pull URL. Versions of BuildStream which contain
this commit will not be able to communicate over SSH with artifact
caches that have not been updated to the same version.
Currently this is just used to double-check user configuration, but we
can now simplify the user facing configuration for artifact caches
completely.
|
|
|
|
|
|
|
| |
Used the packages names we use for the docker containers we
use for CI, which are fedora based.
Fingers crossed that this is the right set of package names.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Consequently:
o Changed Plugin.get_context() to a private Plugin._get_context() accessor.
o Updated anything which imports Context to do so from private _context module
o Updated docs to exclude the now private Context
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If run with no arguments, `bst-here` now opens an interactive Bash
shell. This has several advantages to running each `bst` command
in a new container:
* it's faster
* bash completions will work
* man pages could work (if the user runs `dnf install man`)
If run with arguments, those are now assumed to be arguments for `bst`
such that instead of running `bst-here bst build foo` you now just run
`bst-here build foo`.
|
| |
|
| |
|
| |
|