Closed atjn closed 3 months ago
Thanks! I think in theory this is good, but I'm just thinking:
Sure, if you want me to integrate it directly with the standard build system, I can do that.
Sure, if you want me to integrate it directly with the standard build system, I can do that.
Thanks - I think that would be nice. If you want to keep the action so that emulator builds can be triggered with a few clicks that would be great, but I think it would be nice to do it via the build system rather than by cloning EspruinoWebIDE (as I never liked the extras
directory and it might change at some point anyway).
I think this is ready now.
The standard firmware build is extended to also build the two banglejs emulators.
I have added the option to manually disable each job. If you only want to build the emulators, you can disable main
, dfu
and padded
, which means you only generate builds for the EMSCRIPTEN
and EMSCRIPTEN2
boards. I initially wanted to make this even more customizable, so you could specify exactly which individual boards you wanted to build for ( e.g only BANGLEJS2 and EMSCRIPTEN2), but Github Actions seems too limited to support that, so this is a practical solution that allows you to disable most of the builds that you don't need :)
This looks great, thanks! I guess building the emulators for each CI run automatically is ok - maybe at some point if GitHub starts imposing compute limits we'll need to look again at that though.
Just looking at https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#providing-inputs
It seems like maybe rather than disabling jobs we could have:
inputs:
boardFirmware:
description: 'Firmware to build'
required: true
default: 'default'
type: choice
options:
- BANGLEJS
- BANGLEJS2
- EMSCRIPTEN
- EMSCRIPTEN2
- .....all board files listed here...
So then we could have a separate build task which only ran when boardFirmware
wasn't default
and which built just that board firmware?
Not sure what you think about that, but it feels like it'd be a really nice addition. At the end of the day having to click the actions button twice to build two firmwares isn't a big deal.
Your proposed solution sounds better than mine, but I am not sure how you would implement it. If I just define a random board, how do you know whether to run it with or without e.g. DFU_UPDATE_BUILD
?
It is probably possible but it would require a rewrite of the entire action, and I am not sure the new code would be very developer-friendly because it has to work around the limitations of the GitHub YAML format. If you want, I can give it a shot, maybe in a separate PR.
If I just define a random board, how do you know whether to run it with or without e.g. DFU_UPDATE_BUILD?
True. If that isn't defined, a hex file will still be generated, but I guess that's probably not what people want in most cases.
Actually having a checkbox for that would probably be ideal though as sometimes people do want the hex (eg if having to flash via SWD).
But yes, lets merge this in for now anyway - it can always be changed
It is currently a lot of work to set up your environment so that you can compile the banglejs emulators. I suggest adding a new workflow file that anyone can run to quickly and easily compile the emulators.
The workflow does not run by default, so it does not have any negative impact on the normal use of this repo. It is just available as something that users can manually trigger in their own local forks.