espruino / Espruino

The Espruino JavaScript interpreter - Official Repo
http://www.espruino.com/
Other
2.73k stars 741 forks source link

Build emulators in workflow #2479

Closed atjn closed 3 months ago

atjn commented 3 months ago

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.

gfwilliams commented 3 months ago

Thanks! I think in theory this is good, but I'm just thinking:

atjn commented 3 months ago

Sure, if you want me to integrate it directly with the standard build system, I can do that.

gfwilliams commented 3 months ago

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).

atjn commented 3 months ago

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 :)

gfwilliams commented 3 months ago

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.

atjn commented 3 months ago

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.

gfwilliams commented 3 months ago

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