Automated layout download & compilation in GitHub Action

[Phoscur]

Includes npm lockfile version update(!).

Closes #1

First successful release build: https://github.com/Phoscur/ergodox-macro-hax/releases/tag/PqjlE-v0

The pipeline produce firmware binaries on every push, not only when pushing tags (those create releases like above): https://github.com/Phoscur/ergodox-macro-hax/actions/runs/1731129736

latest updates:

• done refactor add option INPUT_KEYMAP & INPUT_KEYBOARD in Phoscur/QMK-compile
• won't do add INPUT_QMK_BRANCH etc options for different qmk_firmware setup branches (oryx is also zsa specific)

[Phoscur]

@eric-fulfil @gittyeric Works, if you want I can groom my commits a bit more, or do you want to squash anyways?

Seems keymap names should also be in github secrets, or is there a better way to make them configurable in a fork?

[gittyeric]

@eric-fulfil @gittyeric Works, if you want I can groom my commits a bit more, or do you want to squash anyways?

Seems keymap names should also be in github secrets, or is there a better way to make them configurable in a fork?

Sorry I'm catching up here and merging the PRs in now that I'm on the right account. I'm not quite clearly seeing the need for secrets? I must be missing something.

[gittyeric]

@Phoscur Ah shoot, I'd resolve this conflict myself if I could but maybe you could merge this master in your fork, run npm ci to rebuild package-lock.json then I'll go ahead and merge this in.

[gittyeric]

Also finally figured out how to give you write access since last attempt I was on the wrong account 😆 . If you accept the invite I'll just give you write and I'll check in on PRs and merges here and there. Thanks for making this hack a full fledged service.

[Phoscur]

@Phoscur Ah shoot, I'd resolve this conflict myself if I could but maybe you could merge this master in your fork, run npm ci to rebuild package-lock.json then I'll go ahead and merge this in.

Not really - full npm i instead! I have new dependencies, so I had reason to include a new lockfile beside its version update (while the colliding PR did not :|).

Well I was thinking of squashing anyways so I'll do that.

[Phoscur]

Also finally figured out how to give you write access since last attempt I was on the wrong account 😆 . If you accept the invite I'll just give you write and I'll check in on PRs and merges here and there. Thanks for making this hack a full fledged service.

Thank you, after fixing the conflict, I am now able to merge!

[Phoscur]

@eric-fulfil @gittyeric Works, if you want I can groom my commits a bit more, or do you want to squash anyways? Seems keymap names should also be in github secrets, or is there a better way to make them configurable in a fork?

Sorry I'm catching up here and merging the PRs in now that I'm on the right account. I'm not quite clearly seeing the need for secrets? I must be missing something.

It seems to be the only "easy" way to make these env vars configurable in a fork (without changing the pipeline process.yml itself).

Create LAYOUT_ID and LAYOUT_FOLDER secrets so the pipeline runs for your keymap in this main repo.

Please check the readme again and then approve :)

[Phoscur]

Mhh, but it runs my-macros.ts instead, not your illicit ones. We haven't fully decided how sharing macro configurations between forks is supposed to work. We could put them into a folder by username macros/<username>.ts, then at least that does not need to be configured by Github Secret!

[gittyeric]

I like the idea of user folders or app-based folders. In a more "main" file the user could then compose lots of app scripts or something nifty like that if we wanted to overkill it.

[Phoscur]

containerizing the process in docker

That is already what's happening here, see https://github.com/Phoscur/QMK-compile/blob/main/entrypoint.sh taking over the copying of the artifacts to the right location too.