feat: GitHub Action annotations for failed builds

[dxmh]

To try and make the GitHub build experience more user-friendly, I've added a step to the workflow to produce annotations when west build fails. These annotations are shown on the page where a user would go to download their firmware.

A failure will produce a notice informing the user the build has failed and where they can find help:

Additionally, I've included annotations to help with what I believe to be the top 3 most common issues users have on the ZMK Discord server. We can add additional annotations as and when necessary.

Annotation for errors due to incorrect keycodes:

e.g. &kp SLSH instead of &kp SLASH

Error message in log:

Error: nice_nano.dts.pre.tmp:74.137-138 syntax error

Annotation for errors due to incorrect phandle references:

e.g. &kc ENTER instead of &kp ENTER

Error message in log:

nice_nano.dts.pre.tmp:734.14-741.5: ERROR (phandle_references): /keymap/base_layer: Reference to non-existent node or label "kc"

Annotation for errors due to missing parameters:

e.g. &mt LALT instead of &mt LALT F

Error message in log:

zephyr/include/generated/devicetree_unfixed.h:1415:44: error: 'DT_N_S_keymap_S_base_layer_P_bindings_IDX_1_PH_P_label' undeclared here (not in a function); did you mean 'DT_N_S_keymap_S_base_layer_P_bindings_IDX_10_PH'?

I have a couple of thoughts:

1. Instead of having all of this inside of workflows/build.yml, we could call a shell script. This would not only keep the yaml file leaner but it would make it easier to test the parsing locally.

2. We could include an error codes for each unique annotation we seek out? For example, errors due to incorrect keycodes such as &kp ENTRE could be prefixed with E101. We could then write about them in more detail on https://zmk.dev/docs/troubleshooting/.

I'm not sure if these need to be solved now or if they can wait until later.

Please let me know what you think!

[dxmh]

After some conversations on Discord back in December, I started to move this work into a script that could reside in the main ZMK firmware repo (and executed via Github Actions), so that

1. the parsing can be kept up-to-date as work on ZMK progresses (without requiring changes to files in users zmk-config repos)
2. and so that users can run this script from their local machine to get the same troubleshooting information that GitHub provides

Unfortunately I didn't get a chance to complete this work, but I thought it would be worth sharing my initial progress here for future reference: dxmh/zmk@3ad9c44

[petejohanson]

After some conversations on Discord back in December, I started to move this work into a script that could reside in the main ZMK firmware repo (and executed via Github Actions), so that

1. the parsing can be kept up-to-date as work on ZMK progresses (without requiring changes to files in users `zmk-config` repos)

2. and so that users can run this script from their local machine to get the same troubleshooting information that GitHub provides

Unfortunately I didn't get a chance to complete this work, but I thought it would be worth sharing my initial progress here for future reference: dxmh/zmk@3ad9c44

@dxmh Did you see #4 ?

[dxmh]

#4 is awesome. In the scope of this PR (#2), I understand that once #4 has been rolled out, there will no longer be the issue of needing to update files in users zmk-config repos if we need to add/update the logic that produces Annotations, because we can maintain a step in the global/reusable GH Workflow in the main ZMK repo (as this would be used by all users). 🎉

I do think the parsing and output of hints/annotations would be best done by a more complete script (be it shell/python/etc) – it would be easier to maintain and test, and has the benefit of local usage. But if we wanted to get the GH Annotations to users sooner rather than later, a step like the one added in this PR (#2) could be easily added "in-workflow" once #4 lands, and easily swapped out to execute a script later down the line.