Extend CI/CD to build firmware for all hardware

[glopesdev]

Using an external Makefile to build the firmware will ensure that the same steps are used when building the firmware either from Atmel Studio or through the CI pipeline.

Firmware build step on GitHub Actions workflow uses the same AVR-GCC toolchain version to ensure reproducible builds. Version numbers are defined using conditional preprocessor flags which are overridden via Makefile variables to allow building for different hardware targets.

[glopesdev]

Feedback from SRM:

• Firmware build artifacts should be tagged with a suffix that clearly indicates they are preview builds, e.g. commit hash. Toolkit firmware update tool may need to take this suffix into account when parsing file names.
  • Alternatives:
    • commit hash (preferred, could be leveraged to inject in the tag release): Behavior-fw3.3-harp1.15-hw2.0-ass0-commitsha.hex
    • ci build counter (could be a temporary fix, since this is a numeric counter it would be compatible with the current format regex for firmware "previews"): Behavior-fw3.3-harp1.15-hw2.0-ass0-preview21.hex
    • both: Behavior-fw3.3-harp1.15-hw2.0-ass0-commitsha-ci21.hex
• In the future we will also inject the device sha in the firmware build, but not right now.
• Review naming convention for firmware .hex files. Make a proposal for this that also takes into account the pico firmware release names, e.g. .uf2 files.

[glopesdev]

@bruno-f-cruz Added the preview suffix for all CI firmware artifacts. Conditional removal of the suffix for releases will be resolved on the next PR which expands this workflow to upload release assets.

As discussed we will temporarily use the preview suffix with the workflow run number until we review the firmware file naming conventions in the protocol.

[glopesdev]

@bruno-f-cruz We floated briefly the idea of embedding the device.yml in the release assets. I am of two minds here, depending on how we ultimately figure out the following versioning problem:

• Traditionally release versions have been determined exclusively by the act of release, and nothing in the source code specifies directly what these are other than perhaps some build system defaults for local builds.
• Currently, we cannot adopt this default as-is because of the versions specified in the device.yml file, specifically firmwareVersion and hardwareTargets.
• We have to pick between one of the two alternatives:
  • Keep the versions in the device.yml. If we do this, we need to make them the source of truth for all versions propagated throughout the build system. A new helper script probably needs to be made to open and pull this info from the file. In this case, I don't think we need to include the device.yml in the release assets, as a known link to it can be obtained directly from the release tag.
  • Remove the versions from the device.yml. The configured build version from CI becomes the source of truth, which gets injected into the device.yml during build, and propagated to all other builds. In the end we could compile a "frozen" device.yml to include in the release assets which includes the version information for that specific distribution.

I believe both can work. I like conceptually the idea of simply using the github release tag as the point where we "choose" our versions, same as with other bonsai packages. Otherwise, there is always the possibility of a mismatch between what is in written in the device.yml and what the person making the release types in the tag textbox for a GitHub release. The other source of "confusion" is if we forget to update the version immediately following a release, and start making changes, you can generate incorrectly labelled "preview artifacts" pointing to the previous release, when in fact they are from a future release.

On the other hand, pulling everything from the device.yml would impose fewer changes on the YML itself and in some ways make local builds more clear, as they won't rely on access to git information.

[glopesdev]

Keep the versions in the device.yml. If we do this, we need to make them the source of truth for all versions propagated throughout the build system.

For future reference, we ended up going this route, and made all changes required to unify device.yml and release tags into a consistent source of versioning information using harp-tech/configure-build.