Tristan Van Berkom pushed to branch tristan/docs-version-badge at BuildStream / buildstream
Commits:
-
4e2c8b49
by Tristan Van Berkom at 2018-08-29T07:11:08Z
-
79e13826
by Tristan Van Berkom at 2018-08-29T07:11:08Z
-
0f5ecbdb
by Tristan Van Berkom at 2018-08-29T09:34:08Z
8 changed files:
- .gitlab-ci.yml
- README.rst
- doc/source/install_versions.rst
- doc/source/main_about.rst
- + doc/source/main_about_content.rst
- doc/source/main_install.rst
- + doc/source/release-badge.rst
- + doc/source/snapshot-badge.rst
Changes:
... | ... | @@ -50,89 +50,6 @@ source_dist: |
50 | 50 |
# Test stage #
|
51 | 51 |
#####################################################
|
52 | 52 |
|
53 |
-# Run premerge commits
|
|
54 |
-#
|
|
55 |
-.linux-tests-template: &linux-tests
|
|
56 |
- stage: test
|
|
57 |
- variables:
|
|
58 |
- PYTEST_ADDOPTS: "--color=yes"
|
|
59 |
- script:
|
|
60 |
- # Diagnostics
|
|
61 |
- - mount
|
|
62 |
- - df -h
|
|
63 |
- |
|
64 |
- - useradd -Um buildstream
|
|
65 |
- - chown -R buildstream:buildstream .
|
|
66 |
- |
|
67 |
- - export INTEGRATION_CACHE="$(pwd)/cache/integration-cache"
|
|
68 |
- |
|
69 |
- # Unpack and get into dist/buildstream
|
|
70 |
- - cd dist && ./unpack.sh
|
|
71 |
- - chown -R buildstream:buildstream buildstream
|
|
72 |
- - cd buildstream
|
|
73 |
- |
|
74 |
- # Run the tests from the source distribution, We run as a simple
|
|
75 |
- # user to test for permission issues
|
|
76 |
- - su buildstream -c 'python3 setup.py test --index-url invalid://uri --addopts --integration'
|
|
77 |
- |
|
78 |
- # Go back to the toplevel and collect our reports
|
|
79 |
- - cd ../..
|
|
80 |
- - mkdir -p coverage-linux/
|
|
81 |
- - cp dist/buildstream/.coverage.* coverage-linux/coverage."${CI_JOB_NAME}"
|
|
82 |
- artifacts:
|
|
83 |
- paths:
|
|
84 |
- - coverage-linux/
|
|
85 |
- |
|
86 |
-tests-debian-9:
|
|
87 |
- image: buildstream/testsuite-debian:9-master-114-4cab18e3
|
|
88 |
- <<: *linux-tests
|
|
89 |
- |
|
90 |
-tests-fedora-27:
|
|
91 |
- image: buildstream/testsuite-fedora:27-master-114-4cab18e3
|
|
92 |
- <<: *linux-tests
|
|
93 |
- |
|
94 |
-tests-fedora-28:
|
|
95 |
- image: buildstream/testsuite-fedora:28-master-114-4cab18e3
|
|
96 |
- <<: *linux-tests
|
|
97 |
- |
|
98 |
-tests-ubuntu-18.04:
|
|
99 |
- image: buildstream/testsuite-ubuntu:18.04-master-114-4cab18e3
|
|
100 |
- <<: *linux-tests
|
|
101 |
- |
|
102 |
-tests-unix:
|
|
103 |
- # Use fedora here, to a) run a test on fedora and b) ensure that we
|
|
104 |
- # can get rid of ostree - this is not possible with debian-8
|
|
105 |
- image: buildstream/testsuite-fedora:27-master-114-4cab18e3
|
|
106 |
- stage: test
|
|
107 |
- variables:
|
|
108 |
- BST_FORCE_BACKEND: "unix"
|
|
109 |
- PYTEST_ADDOPTS: "--color=yes"
|
|
110 |
- script:
|
|
111 |
- |
|
112 |
- - export INTEGRATION_CACHE="$(pwd)/cache/integration-cache"
|
|
113 |
- |
|
114 |
- # We remove the Bubblewrap and OSTree packages here so that we catch any
|
|
115 |
- # codepaths that try to use them. Removing OSTree causes fuse-libs to
|
|
116 |
- # disappear unless we mark it as user-installed.
|
|
117 |
- - dnf mark install fuse-libs
|
|
118 |
- - dnf erase -y bubblewrap ostree
|
|
119 |
- |
|
120 |
- # Unpack and get into dist/buildstream
|
|
121 |
- - cd dist && ./unpack.sh && cd buildstream
|
|
122 |
- |
|
123 |
- # Since the unix platform is required to run as root, no user change required
|
|
124 |
- - python3 setup.py test --index-url invalid://uri --addopts --integration
|
|
125 |
- |
|
126 |
- # Go back to the toplevel and collect our reports
|
|
127 |
- - cd ../..
|
|
128 |
- - mkdir -p coverage-unix/
|
|
129 |
- - cp dist/buildstream/.coverage.* coverage-unix/coverage.unix
|
|
130 |
- artifacts:
|
|
131 |
- paths:
|
|
132 |
- - coverage-unix/
|
|
133 |
- - logs-unix/
|
|
134 |
- |
|
135 |
- |
|
136 | 53 |
# Automatically build documentation for every commit, we want to know
|
137 | 54 |
# if building documentation fails even if we're not deploying it.
|
138 | 55 |
# Note: We still do not enforce a consistent installation of python3-sphinx,
|
... | ... | @@ -153,78 +70,10 @@ docs: |
153 | 70 |
- public/
|
154 | 71 |
|
155 | 72 |
|
156 |
-# Check code quality with gitlab's built-in feature.
|
|
157 |
-#
|
|
158 |
-code_quality:
|
|
159 |
- image: docker:stable
|
|
160 |
- stage: test
|
|
161 |
- variables:
|
|
162 |
- DOCKER_DRIVER: overlay2
|
|
163 |
- allow_failure: true
|
|
164 |
- services:
|
|
165 |
- - docker:stable-dind
|
|
166 |
- script:
|
|
167 |
- - export SP_VERSION=$(echo "$CI_SERVER_VERSION" | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1-\2-stable/')
|
|
168 |
- - docker run
|
|
169 |
- --env SOURCE_CODE="$PWD"
|
|
170 |
- --volume "$PWD":/code
|
|
171 |
- --volume /var/run/docker.sock:/var/run/docker.sock
|
|
172 |
- "registry.gitlab.com/gitlab-org/security-products/codequality:$SP_VERSION" /code
|
|
173 |
- artifacts:
|
|
174 |
- paths: [gl-code-quality-report.json]
|
|
175 |
- |
|
176 | 73 |
#####################################################
|
177 | 74 |
# Post stage #
|
178 | 75 |
#####################################################
|
179 | 76 |
|
180 |
-analysis:
|
|
181 |
- stage: post
|
|
182 |
- script:
|
|
183 |
- - |
|
|
184 |
- pip3 install radon
|
|
185 |
- mkdir analysis
|
|
186 |
- |
|
187 |
- - |
|
|
188 |
- echo "Calculating Maintainability Index"
|
|
189 |
- radon mi -s -j buildstream > analysis/mi.json
|
|
190 |
- radon mi -s buildstream
|
|
191 |
- |
|
192 |
- - |
|
|
193 |
- echo "Calculating Cyclomatic Complexity"
|
|
194 |
- radon cc -a -s -j buildstream > analysis/cc.json
|
|
195 |
- radon cc -a -s buildstream
|
|
196 |
- |
|
197 |
- - |
|
|
198 |
- echo "Calculating Raw Metrics"
|
|
199 |
- radon raw -s -j buildstream > analysis/raw.json
|
|
200 |
- radon raw -s buildstream
|
|
201 |
- |
|
202 |
- artifacts:
|
|
203 |
- paths:
|
|
204 |
- - analysis/
|
|
205 |
- |
|
206 |
-# Collate coverage reports
|
|
207 |
-#
|
|
208 |
-coverage:
|
|
209 |
- stage: post
|
|
210 |
- coverage: '/TOTAL +\d+ +\d+ +(\d+\.\d+)%/'
|
|
211 |
- script:
|
|
212 |
- - cd dist && ./unpack.sh && cd buildstream
|
|
213 |
- - pip3 install --no-index .
|
|
214 |
- - mkdir report
|
|
215 |
- - cd report
|
|
216 |
- - cp ../../../coverage-unix/coverage.unix .
|
|
217 |
- - cp ../../../coverage-linux/coverage.* .
|
|
218 |
- - ls coverage.*
|
|
219 |
- - coverage combine --rcfile=../.coveragerc -a coverage.*
|
|
220 |
- - coverage report --rcfile=../.coveragerc -m
|
|
221 |
- dependencies:
|
|
222 |
- - tests-debian-9
|
|
223 |
- - tests-fedora-27
|
|
224 |
- - tests-fedora-28
|
|
225 |
- - tests-unix
|
|
226 |
- - source_dist
|
|
227 |
- |
|
228 | 77 |
# Deploy, only for merges which land on master branch.
|
229 | 78 |
#
|
230 | 79 |
pages:
|
... | ... | @@ -248,3 +97,4 @@ pages: |
248 | 97 |
# See https://gitlab.com/gitlab-org/gitlab-ce/issues/35141
|
249 | 98 |
#
|
250 | 99 |
- master
|
100 |
+ - tristan/docs-version-badge
|
... | ... | @@ -14,82 +14,4 @@ About |
14 | 14 |
:target: https://gitlab.com/BuildStream/buildstream/commits/master
|
15 | 15 |
|
16 | 16 |
|
17 |
-What is BuildStream?
|
|
18 |
-====================
|
|
19 |
-BuildStream is a Free Software tool for building/integrating software stacks.
|
|
20 |
-It takes inspiration, lessons and use-cases from various projects including
|
|
21 |
-OBS, Reproducible Builds, Yocto, Baserock, Buildroot, Aboriginal, GNOME Continuous,
|
|
22 |
-JHBuild, Flatpak Builder and Android repo.
|
|
23 |
- |
|
24 |
-BuildStream supports multiple build-systems (e.g. autotools, cmake, cpan, distutils,
|
|
25 |
-make, meson, qmake), and can create outputs in a range of formats (e.g. debian packages,
|
|
26 |
-flatpak runtimes, sysroots, system images) for multiple platforms and chipsets.
|
|
27 |
- |
|
28 |
- |
|
29 |
-Why should I use BuildStream?
|
|
30 |
-=============================
|
|
31 |
-BuildStream offers the following advantages:
|
|
32 |
- |
|
33 |
-* **Declarative build instructions/definitions**
|
|
34 |
- |
|
35 |
- BuildStream provides a flexible and extensible framework for the modelling
|
|
36 |
- of software build pipelines in a declarative YAML format, which allows you to
|
|
37 |
- manipulate filesystem data in a controlled, reproducible sandboxed environment.
|
|
38 |
- |
|
39 |
-* **Support for developer and integrator workflows**
|
|
40 |
- |
|
41 |
- BuildStream provides traceability and reproducibility for integrators handling
|
|
42 |
- stacks of hundreds/thousands of components, as well as workspace features and
|
|
43 |
- shortcuts to minimise cycle-time for developers.
|
|
44 |
- |
|
45 |
-* **Fast and predictable**
|
|
46 |
- |
|
47 |
- BuildStream can cache previous builds and track changes to source file content
|
|
48 |
- and build/config commands. BuildStream only rebuilds the things that have changed.
|
|
49 |
- |
|
50 |
-* **Extensible**
|
|
51 |
- |
|
52 |
- You can extend BuildStream to support your favourite build-system.
|
|
53 |
- |
|
54 |
-* **Bootstrap toolchains and bootable systems**
|
|
55 |
- |
|
56 |
- BuildStream can create full systems and complete toolchains from scratch, for
|
|
57 |
- a range of ISAs including x86_32, x86_64, ARMv7, ARMv8, MIPS.
|
|
58 |
- |
|
59 |
- |
|
60 |
-How do I use BuildStream?
|
|
61 |
-=========================
|
|
62 |
-Please refer to the `documentation <https://buildstream.gitlab.io/buildstream/>`_
|
|
63 |
-for information about installing BuildStream, and about the BuildStream YAML format
|
|
64 |
-and plugin options.
|
|
65 |
- |
|
66 |
- |
|
67 |
-How does BuildStream work?
|
|
68 |
-==========================
|
|
69 |
-BuildStream operates on a set of YAML files (.bst files), as follows:
|
|
70 |
- |
|
71 |
-* Loads the YAML files which describe the target(s) and all dependencies.
|
|
72 |
-* Evaluates the version information and build instructions to calculate a build
|
|
73 |
- graph for the target(s) and all dependencies and unique cache-keys for each
|
|
74 |
- element.
|
|
75 |
-* Retrieves previously built elements (artifacts) from a local/remote cache, or
|
|
76 |
- builds the elements in a sandboxed environment using the instructions declared
|
|
77 |
- in the .bst files.
|
|
78 |
-* Transforms/configures and/or deploys the resulting target(s) based on the
|
|
79 |
- instructions declared in the .bst files.
|
|
80 |
- |
|
81 |
- |
|
82 |
-How can I get started?
|
|
83 |
-======================
|
|
84 |
-To get started, first `install BuildStream by following the installation guide
|
|
85 |
-<https://buildstream.gitlab.io/buildstream/main_install.html>`_
|
|
86 |
-and then follow our tutorial in the
|
|
87 |
-`user guide <https://buildstream.gitlab.io/buildstream/main_using.html>`_.
|
|
88 |
- |
|
89 |
-We also recommend exploring some existing BuildStream projects:
|
|
90 |
- |
|
91 |
-* https://gitlab.gnome.org/GNOME/gnome-build-meta/
|
|
92 |
-* https://gitlab.com/freedesktop-sdk/freedesktop-sdk
|
|
93 |
-* https://gitlab.com/baserock/definitions
|
|
94 |
- |
|
95 |
-If you have any questions please ask on our `#buildstream <irc://irc.gnome.org/buildstream>`_ channel in `irc.gnome.org <irc://irc.gnome.org>`_
|
|
17 |
+.. include:: doc/source/main_about_content.rst
|
... | ... | @@ -13,8 +13,12 @@ For example, for a given version number ``X.Y.Z`` |
13 | 13 |
* The ``X.<odd number>.*`` versions are development spanshots intended for testing.
|
14 | 14 |
|
15 | 15 |
If you are :ref:`installing from git <install_git_checkout>`, please look for the latest
|
16 |
-tag in the latest release branch to ensure you're getting the latest release.
|
|
16 |
+tag to ensure you're getting the latest release.
|
|
17 | 17 |
|
18 |
-Current release branches:
|
|
19 |
- * `bst-1.2 (latest) <https://gitlab.com/BuildStream/buildstream/commits/bst-1.2>`_
|
|
20 |
- * `bst-1.0 (deprecated) <https://gitlab.com/BuildStream/buildstream/commits/bst-1.0>`_
|
|
18 |
+* Latest release:
|
|
19 |
+ |
|
20 |
+ .. include:: release-badge.rst
|
|
21 |
+ |
|
22 |
+* Latest development snapshot:
|
|
23 |
+ |
|
24 |
+ .. include:: snapshot-badge.rst
|
1 |
-.. include:: ../../README.rst
|
|
1 |
+About
|
|
2 |
+-----
|
|
3 |
+ |
|
4 |
+.. include:: release-badge.rst
|
|
5 |
+ |
|
6 |
+.. include:: snapshot-badge.rst
|
|
7 |
+ |
|
8 |
+.. image:: https://gitlab.com/BuildStream/buildstream/badges/master/pipeline.svg
|
|
9 |
+ :target: https://gitlab.com/BuildStream/buildstream/commits/master
|
|
10 |
+ |
|
11 |
+.. image:: https://gitlab.com/BuildStream/buildstream/badges/master/coverage.svg?job=coverage
|
|
12 |
+ :target: https://gitlab.com/BuildStream/buildstream/commits/master
|
|
13 |
+ |
|
14 |
+ |
|
15 |
+.. include:: main_about_content.rst
|
1 |
+ |
|
2 |
+What is BuildStream?
|
|
3 |
+====================
|
|
4 |
+BuildStream is a Free Software tool for building/integrating software stacks.
|
|
5 |
+It takes inspiration, lessons and use-cases from various projects including
|
|
6 |
+OBS, Reproducible Builds, Yocto, Baserock, Buildroot, Aboriginal, GNOME Continuous,
|
|
7 |
+JHBuild, Flatpak Builder and Android repo.
|
|
8 |
+ |
|
9 |
+BuildStream supports multiple build-systems (e.g. autotools, cmake, cpan, distutils,
|
|
10 |
+make, meson, qmake), and can create outputs in a range of formats (e.g. debian packages,
|
|
11 |
+flatpak runtimes, sysroots, system images) for multiple platforms and chipsets.
|
|
12 |
+ |
|
13 |
+ |
|
14 |
+Why should I use BuildStream?
|
|
15 |
+=============================
|
|
16 |
+BuildStream offers the following advantages:
|
|
17 |
+ |
|
18 |
+* **Declarative build instructions/definitions**
|
|
19 |
+ |
|
20 |
+ BuildStream provides a flexible and extensible framework for the modelling
|
|
21 |
+ of software build pipelines in a declarative YAML format, which allows you to
|
|
22 |
+ manipulate filesystem data in a controlled, reproducible sandboxed environment.
|
|
23 |
+ |
|
24 |
+* **Support for developer and integrator workflows**
|
|
25 |
+ |
|
26 |
+ BuildStream provides traceability and reproducibility for integrators handling
|
|
27 |
+ stacks of hundreds/thousands of components, as well as workspace features and
|
|
28 |
+ shortcuts to minimise cycle-time for developers.
|
|
29 |
+ |
|
30 |
+* **Fast and predictable**
|
|
31 |
+ |
|
32 |
+ BuildStream can cache previous builds and track changes to source file content
|
|
33 |
+ and build/config commands. BuildStream only rebuilds the things that have changed.
|
|
34 |
+ |
|
35 |
+* **Extensible**
|
|
36 |
+ |
|
37 |
+ You can extend BuildStream to support your favourite build-system.
|
|
38 |
+ |
|
39 |
+* **Bootstrap toolchains and bootable systems**
|
|
40 |
+ |
|
41 |
+ BuildStream can create full systems and complete toolchains from scratch, for
|
|
42 |
+ a range of ISAs including x86_32, x86_64, ARMv7, ARMv8, MIPS.
|
|
43 |
+ |
|
44 |
+ |
|
45 |
+How do I use BuildStream?
|
|
46 |
+=========================
|
|
47 |
+Please refer to the `documentation <https://buildstream.gitlab.io/buildstream/>`_
|
|
48 |
+for information about installing BuildStream, and about the BuildStream YAML format
|
|
49 |
+and plugin options.
|
|
50 |
+ |
|
51 |
+ |
|
52 |
+How does BuildStream work?
|
|
53 |
+==========================
|
|
54 |
+BuildStream operates on a set of YAML files (.bst files), as follows:
|
|
55 |
+ |
|
56 |
+* Loads the YAML files which describe the target(s) and all dependencies.
|
|
57 |
+* Evaluates the version information and build instructions to calculate a build
|
|
58 |
+ graph for the target(s) and all dependencies and unique cache-keys for each
|
|
59 |
+ element.
|
|
60 |
+* Retrieves previously built elements (artifacts) from a local/remote cache, or
|
|
61 |
+ builds the elements in a sandboxed environment using the instructions declared
|
|
62 |
+ in the .bst files.
|
|
63 |
+* Transforms/configures and/or deploys the resulting target(s) based on the
|
|
64 |
+ instructions declared in the .bst files.
|
|
65 |
+ |
|
66 |
+ |
|
67 |
+How can I get started?
|
|
68 |
+======================
|
|
69 |
+To get started, first `install BuildStream by following the installation guide
|
|
70 |
+<https://buildstream.gitlab.io/buildstream/main_install.html>`_
|
|
71 |
+and then follow our tutorial in the
|
|
72 |
+`user guide <https://buildstream.gitlab.io/buildstream/main_using.html>`_.
|
|
73 |
+ |
|
74 |
+We also recommend exploring some existing BuildStream projects:
|
|
75 |
+ |
|
76 |
+* https://gitlab.gnome.org/GNOME/gnome-build-meta/
|
|
77 |
+* https://gitlab.com/freedesktop-sdk/freedesktop-sdk
|
|
78 |
+* https://gitlab.com/baserock/definitions
|
|
79 |
+ |
|
80 |
+If you have any questions please ask on our `#buildstream <irc://irc.gnome.org/buildstream>`_ channel in `irc.gnome.org <irc://irc.gnome.org>`_
|
... | ... | @@ -4,6 +4,11 @@ |
4 | 4 |
|
5 | 5 |
Install
|
6 | 6 |
=======
|
7 |
+ |
|
8 |
+.. include:: release-badge.rst
|
|
9 |
+ |
|
10 |
+.. include:: snapshot-badge.rst
|
|
11 |
+ |
|
7 | 12 |
This section provides instructions for installing BuildStream and its
|
8 | 13 |
companion artifact server on various platforms, along with any installation
|
9 | 14 |
related materials.
|
1 |
+ |
|
2 |
+.. Use this file to include the badge in the documentation, but not in
|
|
3 |
+ the README.rst or gitlab rendered materials, that doesnt work.
|
|
4 |
+ |
|
5 |
+ Using the <object> tag instead of the <img> tag which sphinx generates
|
|
6 |
+ allows the svg to be "interactive", for us this basically means that
|
|
7 |
+ the link we encode in the badge svg is used, rather than static urls
|
|
8 |
+ which need to be used around the <img> tag.
|
|
9 |
+ |
|
10 |
+ WARNING: The custom CSS on the style tag will need to change if we
|
|
11 |
+ change the theme, so that the <object> tag behaves similar
|
|
12 |
+ to how the <img> tag is themed by the style sheets.
|
|
13 |
+ |
|
14 |
+.. raw:: html
|
|
15 |
+ |
|
16 |
+ <a class="reference external image-reference">
|
|
17 |
+ <object style="margin-bottom:24px;vertical-align:middle"
|
|
18 |
+ data=""
|
|
19 |
+ type="image/svg+xml"/>
|
|
20 |
+ </object>
|
|
21 |
+ </a>
|
1 |
+ |
|
2 |
+.. Use this file to include the badge in the documentation, but not in
|
|
3 |
+ the README.rst or gitlab rendered materials, that doesnt work.
|
|
4 |
+ |
|
5 |
+ Using the <object> tag instead of the <img> tag which sphinx generates
|
|
6 |
+ allows the svg to be "interactive", for us this basically means that
|
|
7 |
+ the link we encode in the badge svg is used, rather than static urls
|
|
8 |
+ which need to be used around the <img> tag.
|
|
9 |
+ |
|
10 |
+ WARNING: The custom CSS on the style tag will need to change if we
|
|
11 |
+ change the theme, so that the <object> tag behaves similar
|
|
12 |
+ to how the <img> tag is themed by the style sheets.
|
|
13 |
+ |
|
14 |
+.. raw:: html
|
|
15 |
+ |
|
16 |
+ <a class="reference external image-reference">
|
|
17 |
+ <object style="margin-bottom:24px;vertical-align:middle"
|
|
18 |
+ data=""
|
|
19 |
+ type="image/svg+xml"/>
|
|
20 |
+ </object>
|
|
21 |
+ </a>
|