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
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
|
=================
buildstream 1.1.4
=================
o `bst workspace` commands and `bst track` will substitute their
source elements when performing those operations, e.g. performing
`bst track` on a filter element will track the sources on the
element that it depends on (if it has sources).
o Added new simple `make` element
=================
buildstream 1.1.3
=================
o BuildStream now requires python version >= 3.5
o Added new `bst init` command to initialize a new project.
o BuildStream will now automatically clean up old artifacts when it
runs out of space. The exact behavior is configurable in
`userconf.yaml`.
o Cross junction tracking is now disabled by default for projects
which can support this by using project.refs ref-storage
New options have been added to explicitly enable cross-junction
tracking.
o Failed jobs are now summarised at the end of a build.
Use `--verbose` and `--no-verbose` to adjust the amount of detail given.
o BuildElements' `configure-commands` are only run once for
workspaces now, which allows for incremental builds.
Appropriate API for plugins is also exposed through
`Element.prepare`.
o The `cmake` plugin now supports building with ninja with the
newly added `generator` configuration option.
o `bst workspace close` and `bst workspace reset` now support multiple
elements. All elements can be specified using `--all`.
o The elements whose cache keys had to be determined during the build
are summarised at the end of the build.
o Fixed versioning introspection to be dynamic, many users use
a developer install mode so they can update with git, now the
version information is always up to date in logs.
This causes a minor API break: The --version output now only
outputs the version.
=================
buildstream 1.1.2
=================
o New ref-storage option allows one to store source refs, such
as git shas, in one central project.refs file instead of inline
with the source declarations.
o Deprecated `--track-save` optionality in `bst build`, this
does not make sense to support now that we have project.refs.
o Added the `sandbox` configuration option which can be used in
`project.conf` and elements, to control the user ID and group ID
used in build sandboxes.
o Added new `deb` source implementation, for staging of downloaded
deb package files.
=================
buildstream 1.1.1
=================
o New project configuration controlling how the sandbox behaves
when `bst shell` is used; allowing projects to provide a more
functional shell environment.
o The `bst shell` command now has a `--mount` option allowing
users to mount files and directories into the sandbox for
testing purposes.
o Log lines are now configurable with the new "message-format"
user configuration, allowing one to express optional fields
such as microsecond precision and wallclock time.
o Newly added filter element
o Git source plugin now allows disabling of submodule checkouts
o In the same way we allow overriding element configurations
by their 'kind' in project.conf, we now support the same
for source plugin configurations.
o Tar and zip sources now automatically recall an `etag`
from the http headers, optimizing tracking of tarballs
significantly (issue #62)
=================
buildstream 1.1.0
=================
o Multiple artifact caches are now supported in project and
user configuration with a priority order (issue #85)
o Add junction support for subprojects
o Changes towards incremental builds in workspaces
o `bst shell --build` now creates true build sandbox
o Many bug fixes
=================
buildstream 1.0.0
=================
First stable release of BuildStream
BuildStream 1.0.0 is all about API stability - for the past months we
have been reviewing our various API surfaces, implementing strategies
for revisioning of our interfaces and cleaning up. Long term stability
is very important for build reproducibility over time, and this release
is the first promise we are making on any API surfaces.
Stable API surfaces include:
o The command line interface
o The YAML user configuration file format
o The YAML project `.bst` file format
o The core Python module imported by external plugins
|
