-
-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add local Docker/Podman build option #6
base: main
Are you sure you want to change the base?
Conversation
This seems useful, but I am worried about people getting confused (in general, in addition to the point I made about the firmware folder). Users already have trouble making assumptions about what files to modify and how, and adding a Makefile and I think with this change we could really use a README or something to tell people what file does what, and what they'd need to modify in order to accomplish what they want to do. However I wouldn't commit to anything before getting the opinion of @petejohanson. |
Ideally, the I can add a README, Below is an example from the Kinesis360 repo showing the different build options: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not generally opposed to this, but I think if we're doing this, it needs some basic documentation as well placed in the repo, or in our main docs site, for how to use this effectively, what it does, etc.
Thanks for the work on this!
@petejohanson, I can PR the |
Hello!
The current method of building the firmware using Github Actions is great for those who are less familiar with the programming world, however, I'm not really a fan of the process (commit, push, wait, download, extract) especially during iterative development---I'd much rather just build locally on my machine.
This PR introduces the option to use Docker/Podman to build the firmware locally (inspired in part by the Kinesis360 Docker build). The Docker image:
build.yaml
to avoid config duplicationbuild
volume which allows subsequent builds to compile fasterfirmware
directoryfirmware
directory whenOUTPUT_ZMK_CONFIG
env variable is setI implemented all of this in my own zmk config repo, however, some of this can be cleaned up by:
build.sh
to the mainzmk
repo (Dockerfile would then copy this in)---this would allow zmk to update as needed without having to sync the file across users' reposyq
(yaml equivalent tojq
) to parse the yaml file, this could possibly be moved into the base imageThanks!