• State Suggested Answer
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 74 subscribers
  • Views 1163 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 297439
Options

Reproducible build

vcbz


I want to achieve reproducible builds on my development machine and a gitlab CI/CD server. So far the generated binary differs if I build locally (VS Code + NRFConnect SDK v2.0.0) and remotely (gitlab CI/CD).

I added the GNU Build ID to verify easily if the builds are the same. I made an example which can be used to test this problem.

How to reproduce

Build with West

git clone https://git.fh-aachen.de/vc9917e/build_id_test.git
west init -m github.com/.../sdk-nrf --mr v2.0.0
west update --narrow -o=--depth=1
west build build_id_test --board nrf52833dk_nrf52833 -- --preset test
arm-zephyr-eabi-readelf -n build/zephyr/zephyr.elf


Build with VScode

1. Clone repo https://git.fh-aachen.de/vc9917e/build_id_test.git
2. Install NRF connect plugin
3. Install NRF Connect SDK v2.0.0
4. Open the NRF connect plugin and select: + Add an existing application
5. Locate the folder where you cloned the repo (step 1)
6. In the "Applications" category of the NRF connect plugin look for the "build_id_test" project and click Add Build Configurtion.
7. Select the CMake presets "test"
9. Click "Build Configuration"  
10. Execute  the following to get the build_id:
       arm-zephyr-eabi-readelf -n build/zephyr/zephyr.elf

After building either with West or VScode and retrieving the GNU Build ID, you will notice it is not the same as the one I automatically generate in the CI/CD in gitlab

https://git.fh-aachen.de/vc9917e/build_id_test/-/jobs/298374


Build ID generated Locally in VSCode:

b559f914e2bcf6b2db403269e121d78cc3c585f0



Build ID generated in Gitlab

8583c3c699d3a160d4fb88b8d71246b31ee69742

You can also download the build files from the GItlab job here

https://git.fh-aachen.de/vc9917e/build_id_test/-/jobs/298374/artifacts/download

About the Gitlab CI/CD

The build process is done based on the docker image from

https://github.com/NordicPlayground/nrf-docker

Which I have modified to install the specific NRF Connect SDK version 2.0.0 and zephyr toolchain SDK v0.14.1 after a discussion over here

https://github.com/NordicPlayground/nrf-docker/discussions/34

In case you want to check what I modified I built the docker image in gitlab and is hosted here

https://git.fh-aachen.de/embeddedtools/nrf-docker/container_registry/1286

Parents
  • 0

    Hi,

    I see you have resolved most of this. A last point is that you need to build with the exact same tools in order to get the same binaries, so the only thing that seems sensible is to also use the docker image in your local builds.

    This seems like a slightly odd requirement though, particularly for development. Out of curiosity, can you share why you want this? I would suggest to keep a local docker image and use that for builds whenever you need something that would be binary identical, but use VS Code with the toolchain from the toolchain manager for every day development and debugging (for simplicity).

Reply
  • 0

    Hi,

    I see you have resolved most of this. A last point is that you need to build with the exact same tools in order to get the same binaries, so the only thing that seems sensible is to also use the docker image in your local builds.

    This seems like a slightly odd requirement though, particularly for development. Out of curiosity, can you share why you want this? I would suggest to keep a local docker image and use that for builds whenever you need something that would be binary identical, but use VS Code with the toolchain from the toolchain manager for every day development and debugging (for simplicity).

Children
  • 0 in reply to Einar Thorsrud

    > A last point is that you need to build with the exact same tools in order to get the same binaries

    Yes, this is what I would think happens in theory in my ci/cd. I have checked the variables passed to cmake. Snippet as ref:

    get_cmake_property(_variableNames VARIABLES)
    list (SORT _variableNames)
    file    (WRITE vars.txt)    
foreach (_variableName ${_variableNames})
    file(APPEND vars.txt "${_variableName}=${${_variableName}}\n")
endforeach()

    I found out in my west native build without vs code, it uses my CMake installation in C:\Prog Files\Cmake

    After uninstalling cmake, and setting the binary path to C:\MY_NCS_SDK_PATH\v2.0.0/opt/bin, I get identical builds between
    west and VS code. I will attempt to fix this in the CI/CD and check if it works.

    And about the requirement, is that we would like to have reproducible builds between CI/CD and local builds. It shouldnt matter if a developer uploads the same compiled source code of a specific commit from local machine or server.
    This also allows to debug the same software release if uploaded from local machine or if it was uploaded via OTA from the gitlab server artifacts.

  • 0 in reply to Einar Thorsrud

    Ok, it seems the binaries are now identical :) It was just that my OS was using another CMAKE version. So basically to reproduce the builds one has to check that the same version bundled by the NRF Connect Desktop app in YOUR_NCS_INSTALL_DIR/YOUR_VERSION/zephyr/opt/bin/cmake (currently cmake 3.20.5) is used.


Related
Terms of service