[feature] allow west to report if any of the cloned repositories is out of sync with the manifest

In order to ensure that a Zephyr application is always built from the exact same sources it would be good if west could report if any of the west-handled repositories is out of sync with the manifest file. Much like a git superproject git status would report a dirty working tree if any of the submodules’ HEADs point to a sha different from the one recorded in the superproject.

$ west forall -c 'git status'
=== running "git status" in manifest (nrf):
HEAD detached at v1.7.0
nothing to commit, working tree clean
=== running "git status" in zephyr (zephyr):
HEAD detached at v2.6.99-ncs1
$ cd -
~/work/zephyr-upstream/zephyr
$ git checkout HEAD^
$ cd -
~/work/zephyr-upstream/nrf
$ west forall -c 'git status'
=== running "git status" in manifest (nrf):
HEAD detached at v1.7.0
nothing to commit, working tree clean
=== running "git status" in zephyr (zephyr):
HEAD detached at 6bfc48ef0b

So basically I rolled back zephyr one commit, but west would not tell me that zephyr’s HEAD is pointing to a different commit than whatever is on nrf/west.yml, which is:

- name: zephyr
        repo-path: sdk-zephyr
        revision: v2.6.99-ncs1

@carlescufi suggested that a new parameter to west list could be used. I don’t have anything against that, I would only suggest the interface to be automation friendly, so that it could be invoked from a build script. If I take git as an analogy, git diff --exit-code would return 1 if anything has been changed from the working tree versus the HEAD revision.

@henrikbrixandersen @mbolivar

[xnlcasad]

thanks @mbolivar for such a complete answer. I agree that given all the use cases that west has to deal with it seems non-trivial to specify a no-surprise, straightforward behaviour to this ‘feature’. I agree with your suggestion of letting the community experiment and come back with a proposal that has proved itself to work in the trenches.

Just fyi, at the moment, we are hardcoding the repos sha1s in the freestanding application’s CMakeLists.txt, like this:

macro(use_ncs_sdk_repo_at_revision path sha1)
   set(repo_${path} ${path} ${sha1})
   list(APPEND repo_list repo_${path})
endmacro()

function(validate_ncs_sdk list_of_repos clean_sdk)
    set(clean_sdk YES PARENT_SCOPE)
    foreach(a ${list_of_repos})
        list(GET ${a} 0 mod_path)
        list(GET ${a} 1 expected_mod_sha)
        message(STATUS "Checking repo: ${mod_path}, expected rev: ${expected_mod_sha}")
        execute_process(COMMAND git -C ${NCS_DIR}/${mod_path} rev-parse HEAD
                        OUTPUT_VARIABLE mod_sha OUTPUT_STRIP_TRAILING_WHITESPACE)
        if (NOT mod_sha STREQUAL expected_mod_sha)
            message(WARNING " repo: ${NCS_DIR}/${mod_path} is not at the expected revision.\n"
                            " expected revision: ${expected_mod_sha}\n"
                            " actual revision  : ${mod_sha}\n")
            set(clean_sdk NO PARENT_SCOPE)
        endif()
        execute_process(COMMAND git -C ${NCS_DIR}/${mod_path} diff --exit-code HEAD
                        RESULT_VARIABLE mod_dirty OUTPUT_QUIET ERROR_QUIET)
        if (mod_dirty STREQUAL 1)
            message(WARNING "repo: ${NCS_DIR}/${mod_path} has modified local files")
            set(clean_sdk NO PARENT_SCOPE)
        endif()
    endforeach(a)
endfunction()

use_ncs_sdk_repo_at_revision(nrf d29f1ddec99b81a66af93b7f0882a7bd0dfa30ee)
use_ncs_sdk_repo_at_revision(zephyr f19ebe4b50405b2eb174199b3635f24d741c9bf4)
use_ncs_sdk_repo_at_revision(nrfxlib a79fdc3dc432e40a13d9c631582aa5f83ea93635)
use_ncs_sdk_repo_at_revision(bootloader/mcuboot b514a3190821b7721dd6ffcd9940474ebe7a8832)

set(clean_sdk NO)
validate_ncs_sdk("${repo_list}" ${clean_sdk})
if (NOT IGNORE_NCS_SDK_STATE AND NOT clean_sdk)
    message(FATAL_ERROR "you are using an sdk that is not synced to this application")
endif ()

This is enough for our current needs. It has the caveat that this runs only at configure time, so we will need to rework it (maybe reusing or getting inspired from https://stackoverflow.com/a/4318642/2748456) so that configure is (re)triggered on git project status change.

However, I would still be interested in understanding how would west achieve R4 in https://docs.zephyrproject.org/latest/guides/west/why.html#requirements because I dont’t see how to link a freestanding application with a specific version (down to the sha1) of the ncs sdk and its dependencies. This lets me wondering how I would go about bisecting the app’s history accurately.

Then, another part of the problem is that we usually include the sha1 and the dirty status information within the final binary itself, so as to be able to rebuild from the exact same sources any binary found on a final product any time (even years) after the binary was produced. In other words this sha1+dirty information acts like a signature over all the source code used to build the application. I would have expected that west could have provided a similar feature to what git submodules provide, but as it looks, it is a non-trivial endeavour, due to the many other use cases that west has to handle.

IMO, we’ve done a good effort on brainstorming around this, and we see that there are some custom solutions that can be used to achieve this purpose somehow. This is enough for our needs, so I would be OK if you’d decide to close this issue now. Thanks!

[mbolivar-nordic]

I believe that’s why earlier comit eff0e1b was not advertised as “breaking” anything either.

It wasn’t advertised as “breaking” because it omits printing useless information instead of changing the information printed.