Support other keymaps in Miryoku ZMK workflow

[manna-harbour]

@caksoylar Continuing from https://discord.com/channels/574598631399751680/1004051304345239633/1055268362759970866 [SplitKB discord].

[caksoylar]

To summarize, the discussion was about the possibility of factoring out Miryoku ZMK workflows (+ outboards) from the Miryoku layout so that it could be used with different config folders (e.g. containing custom layouts) or even without one at all (to build default keymaps).

[manna-harbour]

The Miryoku ZMK build workflows have extra features compared with the stock ZMK workflow, so it'd be nice to make them available for use with other keymaps.

To do that at the moment you'd fork Miyroku ZMK and replace the keymap file with your own. That would give you the outboards feature and the kconfig and branches options, and also the custom_config option with a manual include in your keymap file. This isn't ideal as you'd have to ignore everything else, including the Miryoku-specific options in the Build Inputs workflow, and also deal with potential merge conflicts with the keymap files.

Better would be to make the workflow usable with other zmk-config repos, optionally moving the workflow into a separate repo. Also, splitting the outboards mechanism out into a new repo would mean it could be maintained separately from Miryoku ZMK.

Some considerations for moving the workflow and outboards into a new repo:

• called reusable workflows run in the context of the zmk-config caller repo
• the Miryoku ZMK workflow follows the documented local build method and doesn't use a manifest in zmk-config
• add an option to specify the config directory
  • not limited to one directory deep as in the stock ZMK workflow
  • potential name collisions with workflow checkout of ZMK and outboard repos, so move to subdirectory?
  • symlinks below parent will still need to work to support current Miryoku ZMK directory structure
• the called workflow repo will need to be checked out to have access to the outboard files
• the custom_config option could be supported by writing to the keymap file directly in a similar fashion to the kconfig option to avoid requiring a manual include
  • the keymap filename is not know by the workflow (versions, left / right) but will a keymap with the same name as the supplied board / shield be used as well as the actual keymap file?
  • change name to keymap or custom keymap
• add option to build with the default keymap
  • don't checkout the zmk-config repo, or remove it
  • disable current error check of not using keymap file in config directory
• add option for artifact base name
• for Miryoku ZMK, combine local reusable workflow with external repo reusable workflow to handle Miryoku-specific options
  • pass generated miryoku artifact base name
  • might be easier to nest
  • might not be possible to do matrix builds across Miryoku-specific and non-Miryoku options if the workflows are separated, unless the matrix is moved to the caller workflow, which might prevent combining artifacts?
• reusable workflows in external repos need to be referenced with ref, preferably a tag

[caksoylar]

It all makes sense to me, thanks for the write up!

the keymap filename is not know by the workflow (versions, left / right) but will a keymap with the same name as the supplied board / shield be used as well as the actual keymap file?

This might be a little problematic; IIRC the shared keymap file keyboard.keymap will override keyboard_left.keymap etc. Without duplicating ZMK's CMake logic to determine the correct keymap filename and altering that, the only way I can think of to augment the DT would be to use shield.overlay file (like keyboard_left.overlay) but that has its own issues where the parsing order can render it useless: zmkfirmware/zmk#1382

I guess I don't know right now what would be the right way to do it but I'll chime in if I can think of something.