Auto Test, Version, Build and Deploy Pipelines

[DreiDe]

For seamless development and testing the developer should not have to care about anything apart from the codebase itself. This means that Pipelines for build and deploy processes have to be set up. In the past this was already possible but since the Winder Codebase is split up into HardwareLibrary and Winder the build fails.

Also the implementation had some flaws:

• Autmatic Changelog builds did never work well
  • Commits had to be prefixed with specific words
  • Changelogs were never built into the final frontend (altough a modal for it exists)
  • (no real commit/merging/branching strategie was appied in the codebase)
• new Versions had to be named manually
  • Naming collisions could be created
  • Some versions were named e.g. milan_fix others had a number 0.1.7
  • although the version number implies semantic versioning it was never proper semantic versioning
• the upload to the update server was kind of hacky
  • Http request from Github Action to custom endpoint at update server with custom private key
  • no possibility to mark versions as development or auto enable update for all non development devices

A new implementation needs the following parts:

• Automatic tests
  • Compile test
  • Testing of all C++ only functions with PlatformIO Unit Testing Tool
  • Run clang formatter with c++ style set in coding standards
  • execute on every pull request
• Automatic builds (in two different repos see #20)
  • see https://github.com/QiTech-Industries/Winder/blob/master/.github/workflows/firmware.yml
  • ability to bake most recent code from HardwareLibrary and Winder into one firmware.bin file
  • Ability to bake in changelogs into the webinterface (set platformio envVar)
  • build with multiple different configurations as we will continue to have various hardware versions
    • Folder with different configuration struct cpp files for every hardware version
    • cpp file naming in sync with hardware id inside db (maybe load all configurations from db where there is a hardware table with descriptions anyways?)
  • execute on every merge into master
• Automatic versioning
  • semver Plugin in Github Actions
  • Versioning based on commit prefixes (MAJOR.MINOR.PATCH)
  • On deploy new tag generation in Github with corresponding artifacts (firmware.bin, spiffs.bin)
  • new tag (release) should contain auto generated changelog (see https://github.com/QiTech-Industries/Winder/blob/master/release-conf.json)
  • purely markdown based changelog (currently html as well as TailwindCSS)
• Automatic deployment
  • see https://github.com/QiTech-Industries/Winder/blob/master/.github/workflows/release_firmware.yml
  • upload to update server via endpoint secured with token (or is there a more standard way?)
  • use Github Deploy keys instead of UPDATE_QITECH_DE secret?
  • additional flag whether it is a development release or can be deployed to all end users
  • additional flag to indicate which hardware version the release is for