jcs.org
"Das U-Boot" Source Tree
1.. SPDX-License-Identifier: GPL-2.0+
2
3Continuous Integration testing
4==============================
5
6All changes require passing our continuous integration tests prior to being
7merged in to mainline. To help facilitate merges being accepted quickly,
8custodians are encouraged but not required to run a pipeline prior to sending a
9pull request. Individual developers submitting significant or widespread
10changes are encouraged to run a pipeline themselves prior to posting.
11
12In order to make this process as easy as possible, the ability to run a CI
13pipeline is provided in both Azure and GitLab. Both of these pipelines perform
14their Linux build jobs on the same Docker container image and to cover the same
15platforms. In addition, Azure is also used to confirm that our host tools can
16be built with mingw to run on Windows.
17
18Each of the pipelines is written in such as way as to be a "world build" style
19test and as such we try and build all possible platforms. In addition, for all
20platforms that support being run in QEMU we run them in QEMU and use our pytest
21suite. See :doc:`py_testing` for more information about those tests.
22
23Azure Pipelines
24---------------
25
26This pipeline is defined in the top-level ``.azure-pipelines.yml`` file.
27Currently there are two ways to run a Microsoft Azure Pipeline test for U-Boot.
28
29The first way is to create an account with Microsoft at
30https://azure.microsoft.com/en-us/services/devops/ and then use the
31``.azure-pipelines.yml`` file in the U-Boot repository as the pipeline
32description.
33
34The second way is to use GitHub. This requires a GitHub account
35and to fork the repository at https://github.com/u-boot/u-boot and to then
36submit a pull request as this will trigger an Azure pipeline run. Clicking on
37your pull request on the list at https://github.com/u-boot/u-boot/pulls and
38then the "Checks" tab will show the results.
39
40GitLab CI Pipelines
41-------------------
42
43This pipeline is defined in the top-level ``.gitlab-ci.yml`` file. Currently,
44we support running GitLab CI pipelines only for custodians, due to the
45resources the project has available. For Custodians, it is a matter of
46enabling the pipeline feature in your project repository following the standard
47GitLab documentation. For non-custodians, the pipeline itself is part of the
48tree and should be able to be used on any GitLab instance, with whatever
49runners you are able to provide. While it is intended to be able to run this
50pipeline on the free public instances provided at https://gitlab.com/ a problem
51with our squashfs tests currently prevents this.
52
53To push to Gitlab without triggering a pipeline use:
54
55.. code-block:: bash
56
57 git push -o ci.skip
58
59Docker container
60----------------
61
62As previously stated, both of the above pipelines build using the same Docker
63container image. This is maintained in the U-Boot source tree at
64``tools/docker/Dockerfile`` and new images are made as needed to support new
65tests or features. This file needs to be updated whenever adding new external
66tool requirements to tests.
67
68Customizing CI
69--------------
70
71As noted above, the CI pipelines perform a world build. While this is good for
72overall project testing, it can be less useful for testing specific cases or
73developing features. In that case, it can be useful as part of your own
74testing cycle to edit these pipelines in separate local commits to pair them
75down to just the jobs you're interested in. These changes must be removed
76prior to submission.