Setup FOTA build tool and GitHub CI workflow #3
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 9 commits
August 5, 2021 02:32
Example-specific application dependencies (such as mcuboot or mbed-os) and build folders and files are now ignored by git, along with IDE-specific files and virtual environment folders.
The requirements bundles both the old and new mbed-clis as the MCUboot example doesn't support building with the new mbed-tools (as of this commit).
This script will be sourced from the main build script and aids in making both the script and its output better readable. The say function prints a given message to the stdout (or stderr) based on the selected formatting mode, and the fail function calls say with error mode and exits with 1.
The script parses and validates arguments passed in by the user and sets up the primary virtual environment with the required dependencies from requirements.txt.
The mock_build function runs the steps required to build the mock example. Please refer to the comments in the script for more information.
The mcuboot_build function runs the steps required to build the MCUboot example. Please refer to the comments in the script for more information.
The fota script now sources the example scripts and calls the build function of the selected example with the validated arguments.
The examples now each contain a clean function that's responsible for cleaning any dependencies or generated build files or folders specific to that example. The fota script's clean function was updated to call these.
The workflow has two jobs, one for each example. Please refer to comments in the file for more information.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
FOTA Build Tool
Currently, to setup the two examples (MCUBoot and Mock) for demonstration, the build instructions in their associated documentation has to be followed step-by-step. This process can be quite cumbersome and isn't entirely ideal for testing.
Instead, this build process can be automated through a simple bash script that performs every step in the build instructions for the end-user - as a result, the
fota.shcli build tool was created. The tool takes in as arguments the example, target board, mount point of target board, and toolchain.There are slight kludges with how the MCUboot and Mock examples are built with
fota.sh. The former is a direct result of dependency conflicts between mbed-tools, pyocd, and mbed-os. The latter is a result of issues with flashing the target binary to the connected board. The details of both are addressed below:Dependency Conflicts: The difference in version requirements of the PyYAML dependency imposed by both mbed-os and pyocd led to the creation of a temporary virtual environment; this is used in the "creating and flashing the factory firmware" stage of the MCUboot example build process. This is a known issue and would require changes to the
requirements.txtfile in the mbed-os to resolve.Another minor conflict that doesn't hinder the build process is one between mbed-tools and mbed-os on the version requirement of the Click dependency; mbed-tools requires that the minimum version of Click to be greater than 7.1 while mbed-os requires it to be greater than 7.0. Now, the dependencies for mbed-os are installed after those of mbed-tools, which overwrites the newer version and generates a conflict. This would (again) require changes to the requirements file in the mbed-os repository to bump up the minimum version number of Click to 7.1.
Target Binary Flashing: For the Mock example, compiling with mbed-tools results in the following error:
The tool is looking for a hex file under the cmake build output whose name comes from project directory (in this case, "target"). However, the generated one is named
BLE_GattServer_FOTAService.hex. Again, this is a known issue and has been filed (282) in the mbed-tools repository by noonfom.GitHub CI Workflow
Currently, there is no CI workflow setup to make sure that both examples build successfully. The aim was to setup a GitHub actions workflow that uses the new CLI build tool
fota.sh(from branch build-process-automation) to build the examples and check for any errors; known issues (documented above) are ignored or have workarounds implemented to avoid them.A GitHub workflow "Build Examples" was created to build the two examples (as two separate jobs). Also, this workflow uses the mbed-os-env container as it bundles the GCC ARM toolchain, along with Python and CMake.
Other Remarks
Pull request #2 was issued from my forked repo's main branch, which saw a quite a lot of commits (67 to be exact) for development work on these two requirements - the commit history was too long to be meaningful and human readable (more information here). As a result, this new pull request is issued with the amended commit history.
The description of this pull request was adapted from the descriptions of issues and pull requests made in my fork.
For the automation script, the aim was to write it in bash as it is widely available and easily maintainable. In the future, the script's functionality could be migrated into a CLI tool written in Python.
It was not a strict requirement to run the examples on the target board using the CI workflow by means of a Raspberry Pi rig connected to an NRF52840_DK target board. However, support for this can be added later considering that the new build tool supports building the examples without providing a mount point.