1# **CI for Yocto Project and meta-arm** 2# **CI for Yocto Project** 3The Yocto Project has an autobuilder that performs nightly builds and image tests on all of the defined QEMU machines, including qemuarm and qemuarm64 Also, it currently runs builds on the hardware reference platforms including genericarm64 and meta-arm mahines fvp-base and sbsa-ref. More information on the autobuilder can be found at <https://autobuilder.yoctoproject.org/>. 4 5More information on the image tests can be found at <https://wiki.yoctoproject.org/wiki/Image_tests>. 6 7The Yocto Project also has the ability to have individual package tests, ptests. For more information on those, go to <https://wiki.yoctoproject.org/wiki/Ptest>. 8# **CI for meta-arm** 9meta-arm is using the Gitlab CI infrastructure. This is currently being done internal to Arm, but an external version can be seen at <https://gitlab.com/jonmason00/meta-arm/-/pipelines>. 10 11This CI is constantly being expanded to provide increased coverage of the software and hardware supported in meta-arm. All platforms are required to add a kas file and `.gitlab-ci.yml` entry as part of the initial patch series. More information on kas can be found at <https://github.com/siemens/kas>. 12 13To this end, it would be wise to run kas locally to verify everything works prior to pushing to the CI build system. 14## **Running kas locally** 15### **Install kas** 16kas can be installed with pip, for example: 17``` 18$ pip3 install --user kas 19``` 20 21See <https://kas.readthedocs.io/en/latest/userguide/getting-started.html> for information on the dependencies and more. 22 23This assumes that the kas path ($HOME/.local/bin) is in $PATH. If not, the user will need to manually add this or the kas command will not be found. 24 25### **Run kas locally** 26``` 27$ cd ~/meta-arm/ 28$ kas build kas/juno.yml 29``` 30 31By default kas will create a build directory under meta-arm to contain the checked out layers, build directory, and downloads. You can change this by setting environment variables. DL\_DIR and SSTATE\_DIR are respected so these can point at existing directories, and setting KAS\_WORK\_DIR to the directory where repositories are already cloned will save having to re-fetch. This can look something like: 32``` 33$ SSTATE_DIR=/builds/persist/sstate DL_DIR=/builds/persist/downloads kas build ci/qemuarm64.yml:ci/testimage.yml 34``` 35 36See the [quick start guide](/documentation/quick-start.md) for more information on how to set this up. 37 38## **Locked Revisions in CI with lockfiles** 39The CI in meta-arm will generate a kas "lock file" when it starts to ensure that all of the builds checkout the same revision of the various different layers that are used. If this isn't done then there's a chance that a layer will be modified upstream during the CI, which results in some builds failing and some builds passing. 40 41This lock file is saved as an artefact of the update-repos job by the CI, and only generated if it doesn't already exist in the repository. This can be used to force specific revisions of layers to be used instead of HEAD, which can be useful if upstream changes are causing problems in development. 42 43The lockfile.yml can be downloaded manually, but there's a script in meta-arm to fetch the lock file for the latest successful build of the specified branch: 44 45``` 46$ ./ci/download-lockfile.py --help 47usage: download-lockfile.py [-h] server project refspec 48 49positional arguments: 50 server GitLab server name 51 project meta-arm project name 52 refspec Branch/commit 53 54$ ./ci/download-lockfile.py https://gitlab.com/jonmason00/meta-arm master 55Fetched lockfile.yml 56Commit this lockfile.yml to the top-level of the meta-arm repository and the CI will use it automatically. 57``` 58# **Relevant Links for kas, CI, and testing** 59<https://github.com/siemens/kas.git> 60 61<https://wiki.yoctoproject.org/wiki/Oe-selftest> 62 63<https://wiki.yoctoproject.org/wiki/Image_tests> 64 65<https://wiki.yoctoproject.org/wiki/Ptest> 66 67<https://wiki.yoctoproject.org/wiki/BSP_Test_Plan> 68