Applications using a West T2 project topology (a.k.a. "Workflow 4" according to Nordic docs) would be downloading their own NCS repo with west in a typical CI/CD situation.
Specifically to our case, we use GitLab CI and we get the manifest repo downloaded before the CI script starts running, so the pre-existing NCS is both a waste of space and an inconvenience.
Sure, we could use the pre-installed NCS if we made sure to pull the docker image that matches the NCS version referenced in our manifest, but that defeats the some of the benefits of the T2 topology, e.g.:
it means that we can't override repos from the NCS manifest to bring in custom changes from our own forks
it means that we can't update our project to a newer version of the NCS until this repo is updated to it and a new image generated
Our first approach was to start our CI script with:
removing the NCS west workspace
west init -l in the manifest repo that is being built
west update --narrow -o=--depth=1
redefine ZEPHYR_BASE
start the west build
This works, but it's wasteful of space and slow.
Our second attempt was to fork this repo to remove the NCS installation from the Dockerfile (lines 129:155), then in the CI script:
pull the new "NCS-less" docker image
west init -l in the manifest repo that is being built
west update --narrow -o=--depth=1, which gets the NCS and various repos from the manifest on disk
install the python requirements from the zephyr, nrf and bootloader directories
start the west build
This means that the project is built with the NCS and all other dependencies as defined in the project's manifest.
The drawback is that the python requirements need to be installed as part of the build, which takes some time (but can be cached at the CI level)
In short:
is there a better way (that I couldn't figure out) to use this docker image with a T2 topology?
if the answer is "no, there isn't", I offer to create a PR that makes the installation of NCS conditional to a Dockerfile ARG (I propose the installation is on by default, and the ARG allows skipping it) and explains in README.md how to use this feature. I would like to first check that this approach makes sense, though =)
Applications using a West T2 project topology (a.k.a. "Workflow 4" according to Nordic docs) would be downloading their own NCS repo with
westin a typical CI/CD situation.Specifically to our case, we use GitLab CI and we get the manifest repo downloaded before the CI script starts running, so the pre-existing NCS is both a waste of space and an inconvenience. Sure, we could use the pre-installed NCS if we made sure to pull the docker image that matches the NCS version referenced in our manifest, but that defeats the some of the benefits of the T2 topology, e.g.:
Our first approach was to start our CI script with:
west init -lin the manifest repo that is being builtwest update --narrow -o=--depth=1ZEPHYR_BASEThis works, but it's wasteful of space and slow.
Our second attempt was to fork this repo to remove the NCS installation from the Dockerfile (lines 129:155), then in the CI script:
west init -lin the manifest repo that is being builtwest update --narrow -o=--depth=1, which gets the NCS and various repos from the manifest on diskpythonrequirements from thezephyr,nrfandbootloaderdirectoriesThis means that the project is built with the NCS and all other dependencies as defined in the project's manifest. The drawback is that the
pythonrequirements need to be installed as part of the build, which takes some time (but can be cached at the CI level)In short:
ARG(I propose the installation is on by default, and theARGallows skipping it) and explains inREADME.mdhow to use this feature. I would like to first check that this approach makes sense, though =)