setup continuous integration

[FlorianLudwig]

run build on very commit:

cp src/loraconf.sample.h src/loraconf.h
pip install platformio==3.6.0a1
platformio run -e heltec -e ttgov1 -e ttgov2 -e ttgov21 -e ttgobeam -e fipy -e lopy -e lopy4 -e lolin32lite -e lolin32

maybe even check for code guideline violations.

I would like to go with gitlab-ci as a ci system. This would (more long term) allow for a custom runner that does not just build but also deploys on a board and does some simple checks if it still works.

[cyberman54]

CI within github was on my wishlist / todolist. Thanks for this enhancement.

Now we miss CD by OTA, maybe later by FUOTA :-)

[FlorianLudwig]

@cyberman54 so you are fine with gitlab-ci?

Actually I created a ci pipeline over at gitlab.com to test it some time ago: https://gitlab.com/GreyRook/ESP32-Paxcounter/-/jobs/68196378

For the next level: @heerben Can you discus with Marius how to setup a gitlab runner that is able to put a fipy into flash-mode, reboot it, flash it, put it back into normal mode and reboot it again ;) Thanks

OTA... well, ... That might actually be easier since there are less security concerns with people being able to execute arbitrary on a device/vm with access some level of access to the usb-subsystem plus being in your local network.

[cyberman54]

ok!

[cyberman54]

But we need platformio 3.6 for CI. Otherwise automatic upload size limit adaption to the flash partition table resizing won't work.

Current: PlatformIO, version 3.6.0a1

[lyusupov]

FYI: you may consider to try this: https://www.virtualhere.com/ (USB-over-TCP, port 7575) as a tool for:

• to remotely flash firmware binaries into a target board ;
• to remotely monitor boot sequence over UART.

This works for me. I have build server in a cloud and the target board is local. Flashing speed is low but still acceptable. Stability of connection is good: 24+ hours.

[t-huyeng]

Since the first basic workflow is now part of this repo next steps as mentioned in #903 :

• [x] improve test coverage by automatically changing board definitions I am not sure yet how to implement this because it looks like we need to override build_flags_basic with -include "src/hal/${board.halfile}" with the board name. Done see #906 and #907
• [x] check if cache (github workflow) is used correctly
  Cache is at least reused on master and development branch
• [x] reduce runtime to run only on approved pull requests and pushes to master

~- [ ] Check why Linux- Cache is 630mb big~ ~- [ ] improve test coverage by automatically changing certain #define settings in paxcounter.conf (those which control compiler build options : WIFICOUNTER, BLECOUNTER, BOOTMENU, USE_OTA)~

[t-huyeng]

@FlorianLudwig you test for each board with a separate environment if I understand: platformio run -e heltec -e ttgov1 -e ttgov2 -e ttgov21 -e ttgobeam -e fipy -e lopy -e lopy4 -e lolin32lite -e lolin32 correctly. Did you also have a way of testing for different halfiles?

[cyberman54]

@t-huyeng the comment refers to an earlier version of paxcounter, which had no build logic with hal files for different boards, because all boards used the same board base type ("esp32dev"). Thus, it was possible to build code for different environments this way. Meanwhile a build logic with hal files was added to paxcounter which made this more complex by using a build.py script. This came in as different board types came up. If you find a better way to support different board types, please let uns know. Thank you!

[t-huyeng]

I updated the build script to support a ENV CI_HALFILE for the halfile see #906.

[t-huyeng]

Maybe it would also be enough to run the CI only on approved pull-requests and pushes to the master.

[cyberman54]

Maybe it would also be enough to run the CI only on approved pull-requests and pushes to the master.

Yes, sure.

[t-huyeng]

For this

reduce runtime to run only on approved pull requests and pushes to master

I would set the settings for the action to this (if not already done) :

or maybe even to Require approval for all outside collaborators then you (@cyberman54) or somebody with the rights can approve a the workflow during a pull_request.

[cyberman54]

This setting is already in place for the repository,

[cyberman54]

This was done!