blob: b9468cb004b60b5387b0ea5e72d2623282022330 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
|
:orphan:
.. _public:
Builtin Public Data
===================
Elements can provide public data which can be read by other elements
later in the pipeline, the format for exposing public data on a given
element is :ref:`described here <format_public>`.
Any element may use public data for whatever purpose it wants, but
BuildStream has some built-in expectations of public data, which resides
completely in the ``bst`` domain.
In this section we will describe the public data in the ``bst`` domain.
.. _public_integration:
Integration Commands
--------------------
.. code:: yaml
# Specify some integration commands
public:
bst:
integration-commands:
- /usr/bin/update-fancy-feature-cache
The built-in ``integration-commands`` list indicates that depending elements
should run this set of commands before expecting the staged runtime environment
to be functional.
Typical cases for this include running ``ldconfig`` at the base of a pipeline,
or running commands to update various system caches.
Integration commands of a given element are automatically run by the
:func:`Element.integrate() <buildstream.element.Element.integrate>` method
and are used by various plugins.
Notably the :mod:`BuildElement <buildstream.buildelement>` derived classes
will always integrate the build dependencies after staging and before running
any build commands.
.. _public_split_rules:
Split Rules
-----------
.. code:: yaml
# Specify some split rules
public:
bst:
split-rules:
runtime:
- |
%{bindir}/*
- |
%{sbindir}/*
- |
%{libexecdir}/*
- |
%{libdir}/lib*.so*
Split rules indicate how the output of an element can be categorized
into *domains*.
The ``split-rules`` domains are used by the
:func:`Element.stage_artifact() <buildstream.element.Element.stage_artifact>`
method when deciding what domains of an artifact should be staged.
The strings listed in each domain are first substituted with the
:ref:`variables <format_variables>` in context of the given element, and
then applied as a glob style match, as understood by
:func:`utils.glob() <buildstream.utils.glob>`
This is used for creating compositions with the :mod:`compose <elements.compose>`
element and can be used by other deployment related elements for the purpose of
splitting element artifacts into separate packages.
.. _public_overlap_whitelist:
Overlap whitelist
-----------------
The overlap whitelist indicates which files this element is allowed to overlap
over other elements when staged together with other elements.
Each item in the overlap whitelist has substitutions applied from
:ref:`variables <format_variables>`, and is then applied as a glob-style match
(i.e. :func:`utils.glob() <buildstream.utils.glob>`).
.. code:: yaml
public:
bst:
overlap-whitelist:
- |
%{sysconfdir}/*
- |
/etc/fontcache
|
