| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
name
In core_plugins.rst, we are already using _plugins, _plugins_build_elements,
so lets call this one _plugins_sources to be consistent.
|
| |
|
|
| |
Issue #353
|
| |
|
|
| |
Issue #353
|
| |
|
|
| |
Issue #353
|
| |
|
|
| |
Issue #353
|
| |
|
|
| |
Issue #353
|
| | |
|
| |
|
|
| |
Fixes #435
|
| |
|
|
|
|
|
| |
Correct includsion of buildstream.doap which does not exist
to 'include BuildStream.doap'.
This commit resolves issue #430
|
| |
|
|
|
|
|
|
|
|
|
|
| |
pylint >2 is not compatible with pytest_pylint in its current form. As
such, allowing any version of pylint for testing results in a failure.
This commit restricts down the allowable versions of pylint to those
that are both compatible with pytest_pylint, and also offer the feature
set that we require.
See https://gitlab.com/BuildStream/buildstream/issues/427 for further
details.
|
| |
|
|
| |
Fixes #424
|
| |
|
|
|
|
| |
Place the titles of literally included `bst` files directly before
the includes, and moved all related text to start below the included
file for each section.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Use the following form across the board:
``elements/foo.bst``
~~~~~~~~~~~~~~~~~~~~
.. literalinclude:: ../path/to/foo.bst
:language: yaml
Always use an example project relative path, too.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This part of the tutorial uses a lot of the work from Phil Dawson
and James Ennis, and uses their example submitted on merge request
499 as a basis to introduce the user to yaml composition and variable
resolution.
This is a part of issue #103
|
| |
|
|
| |
And adding some link anchors needed by the incomming chapter.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
o doc/examples/running-commands: New example project of a `manual` build element
o doc/sessions/running-commands.run: New session file to capture bst output
o doc/source/sessions-stored: Added new generated sessions
o doc/source/tutorial/running-commands.rst: New tutorial entry describing how
commands are run in the sandbox
o tests/examples/running-commands.py: Test case validating the tutorial's assertions
|
| |
|
|
|
| |
Linking out to the relevant invoking pages for the command line
reference, and adding a link anchor here for use by the next chapter.
|
| |
|
|
|
|
|
| |
Separate the revisioned provisional session html files such
that the git tree does not become dirty as a result of a
documentation build process - which messes up the docs version
number and the version number printed in some command line output.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
o doc/Makefile: Added new directory to collect rst files from
o doc/examples/first-project: Added the "first-project" example
project.
o doc/source/sessions/first-project-*.html: Added the generated
snippets
o doc/source/using_tutorial.rst: Added the new main tutorial page
o doc/source/tutorial/first-project.rst: Added part 1 of the tutorial here
o tests/examples/first-project.py: Added test for the example project
This is largely based on an example by Javier Jardón, which was
submitted at https://gitlab.com/BuildStream/buildstream/merge_requests/323
Fixes #103
|
| |
|
|
|
|
|
|
|
|
|
| |
If --force is not specified, then we'll skip session files in
the case that all of the outputs exist.
Now setting BST_FORCE_SESSION_REBUILD when building the docs
will cause the session files to be rebuilt regardless of whether
they exist or not.
The .gitlab-ci.yml was also changed to use this and force rebuilds.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When specifying a fake-output string, we don't really run the command
or assume it was a `bst` command, and we pretend that `fake-output`
was the output of the command.
Specifying an empty string explicitly enables the behavior too
for faking a command that has no stdout/stderr.
This also adds the "remove-files" hack allowing the session scripts
to remove files before executing commands (kind of unsure if we're
gonna keep this...)
|
| |
|
|
| |
This list needs to not be quoted.
|
| |
|
|
|
|
|
|
|
|
| |
Before we were creating one description file for each output,
making it easier to declare a make rule for it - but the result
was that we would have to build things more and it takes a
long time.
Instead, now we have session files which describe a series of commands
to run in a session, and each command optionally produces an output file.
|
| |
|
|
|
|
|
|
|
| |
This method doesn't really do anything as this is already the default
behavior of `docker volume create` so remove it and always call
`docker volume create` directly. This command will always print the name
of the volume on STDOUT which is not very interesting so silence that.
(If it errors out for some reason, that output will go to STDERR so the
user should still be able to see that.)
|
| |
|
|
|
| |
As we can only accept arguments when a command is specified, make it
clear in the usage instructions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
o Giving main pages simple word titles
This makes the main page:
* About
* Installing
* Using
* Reference
* Contributing
o Now named all rst files with their parent page name as a prefix.
o Also changed some titles to make overall consistent titles.
|
| |
|
|
|
|
| |
This was a bad idea and doesnt play well with mobile UIs, better
off to just include the whole thing even if it's long, and let
the backing page handle vertical scrolling.
|
| |
|
|
|
| |
Use the gitlab cache for caching sources needed for building projects
in order to collect sample output for documentation pages.
|
| |
|
|
| |
And some instructions about generating `bst` output for documentation
|
| |
|
|
|
|
|
| |
This is only to make it easier for people who just want to
build docs locally and not regenerate the session files.
The session snapshot html files are always generated in CI every time.
|
| |
|
|
| |
subdirectory
|
| |
|
|
| |
Show the commands at work in this example.
|
| |
|
|
|
| |
The Makefile uses these to run some scenarios which are
later included by the documentation directly.
|
| |
|
|
|
|
| |
If you need an example output of bst to put in the documentation,
just add a .run file to the doc/examples directory and it will result
in a similarly named .html file in doc/source/examples.
|
| |
|
|
|
|
|
| |
This baby runs bst and captures the output with colors enabled
and then generates some html we can include in documentation.
These can be generated in CI continuously and used in the documentation.
|
| |
|
|
| |
Fixes issue #380
|
| | |
|
| |
|
|
|
|
| |
Seems that the "commands" is taking a lot of space such that
we can't see the other sections here easily, that is alright
if "commands" remains at the end.
|
| |
|
|
|
| |
Here we're really listing examples, a ToC with depth is
not great here.
|
| |
|
|
| |
project on gitlab.
|
| |
|
|
| |
This was named autotools-flatpak, changed to flatpak-autotools.
|
| |
|
|
|
| |
We still have a few unused artifacts in the docs generation,
this is just one less.
|
