search

lvgl / lv_binding_micropython

LVGL binding for MicroPython
MIT License
250 stars 161 forks source link

Enable Micropython CI workflows #122

Closed amirgon closed 2 years ago

amirgon commented 3 years ago

Currently all Micropython's CI workflows were disabled on https://github.com/lvgl/lv_micropython/commit/43ec34e2760f58299a4f780b602cb335b757476a

With some work, at least some of them can be enabled on lv_micropython.

embeddedt commented 3 years ago

It's probably not worth re-enabling the ports ones (I think ours effectively do the same thing), but the formatting and code size ones look useful.

amirgon commented 3 years ago

It's probably not worth re-enabling the ports ones

My thought was to enable the port ones, specifically ports we don't support yet.
That way we would know it builds on other platforms, and be ready to the moment someone starts using lv_micropython with a new port.

amirgon commented 3 years ago

CI for stm32/esp32/unix ports could also be useful for providing prebuilt firmware effortlessly, as was requested before.

embeddedt commented 3 years ago

@amirgon If you have a moment, can you take a look at the ESP-related commands in this Action, and let me know if I missed something? I think I've followed all the steps correctly but it's not finding some header files.

ESPIDFMOD-GEN build-GENERIC_SPIRAM/espidfmod/mp_espidf.c
In file included from ../../lib/lv_bindings/driver/esp32/espidf.h:101:
/home/runner/work/lv_micropython/lv_micropython/esp-idf/components/esp32/include/esp_clk.h:1:2: warning: #warning esp_clk.h has been replaced by esp32/clk.h, please include esp32/clk.h instead [-Wcpp]
 #warning esp_clk.h has been replaced by esp32/clk.h, please include esp32/clk.h instead
  ^~~~~~~
In file included from ../../lib/lv_bindings/driver/esp32/espidf.h:104:
/home/runner/work/lv_micropython/lv_micropython/esp-idf/components/driver/include/driver/gpio.h:17:10: fatal error: esp_err.h: No such file or directory
 #include "esp_err.h"
          ^~~~~~~~~~~
amirgon commented 3 years ago

@embeddedt my thinking was to enable Micropython's CI instead of creating a custom one.
The advantage is that we would follow upstream more closely. This is especially important now that ESP32 port on Micropython is migrating to CMake.

What do you think?

embeddedt commented 3 years ago

The problem is that MicroPython's CI is not building multiple boards (at least when I investigated it). It is just building enough to verify that compilation still succeeds in general. E.g. for STM32 it is only building pyboard variants.

Do you think it's better to modify their CI script to do that than to make one for our purposes?

amirgon commented 3 years ago

Do you think it's better to modify their CI script to do that than to make one for our purposes?

I don't know about STM32, but for ESP32 the CI is maintained and modified according to build changes.
For example, when Micropython supports a different (or an additional) ESP-IDF version, this is reflected in CI changes.

See for example: https://github.com/micropython/micropython/commit/aa3d6b6aa5ec9fdf15b5c2d30a1c9f9c9064cd3c#diff-398f66844239bcfec34a0362acfee807d8d697c15490291b03bce4904182a45f

So my thinking was - instead of maintaining the CI script separately ourselves and follow build changes, let's reuse Micropython's CI. Instead of modifying their scripts, I thought of trying to call these scripts and add additional actions (such as actions/upload-artifact@v2) where needed.

Creating prebuilt firmware would be nice and useful but I think it's a secondary goal.

stale[bot] commented 3 years ago

This issue or pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

amirgon commented 3 years ago

@kisvegabor, @embeddedt I've enabled ESP32 workflow and I was wondering about providing prebuilt firmware

What do you think?

embeddedt commented 3 years ago

Technically how do we create a prebuilt firmware workflow? Where would we publish the pre-built firmware? What would trigger the workflow?

Take a look at this example:

https://github.com/lvgl/lv_port_stm32f746_disco/blob/master/.github/workflows/stm32_port.yml

We can then use https://nightly.link/ to provide direct links instead of needing to browse to the action artifacts.

amirgon commented 3 years ago

Take a look at this example:

What triggers the workflow? Every push? that could create lots of artifacts. Or do we need some release schedule? Also, I think that GitHub holds artifacts for no longer than 90 days, so I'm not sure about storing artifacts in GitHub.