search

marcelstoer / docker-nodemcu-build

Docker image to build NodeMCU firmware for the ESP8266 on your machine
https://hub.docker.com/r/marcelstoer/nodemcu-build/
MIT License
129 stars 63 forks source link

Allowing an uploadable config for Docker images #6

Closed TerryE closed 8 years ago

TerryE commented 8 years ago

I know we've touched on this on a firmware issue but I use a config script to build my user_*.h files and it is really just so much easier than having to mess around tweaking this -- or in the case fo a cloud build services the potential vulnerabilities / exploits that allowing the direct upload of these files would introduce and an alternative to have to extended the GUI. We could leave the GUI for novice use but allow uploaded configs for advanced configuration. So this is my default config:

;
; ESP-01 512KB Module config
;
flash_size       = 512K
bit_rate         = 115200
client_ssl       = disable
gpio_interrupt   = enable
spiffs_cache     = enable
sha2             = disable
builtin = string,table,coroutine,math,debug_minimal
modules = node,file,gpio,wifi,net,i2c,tmr,uart,ow,bit

The source is here on gist. I chose Lua because this is a Lua project and I need Lua on my host for luac.cross anyway, but this given that docker images don't have Lua installed as standard, we could easily reimplement in Python or even bash.

TerryE commented 8 years ago

@marcelstoer Bump. Either close this or have the discussion.

marcelstoer commented 8 years ago

Sorry Terry, I didn't ignore it on purpose...it must have drowned in a sea of NodeMCU-related messages.

I remember we've touched on this on a firmware issue and I'd very much welcome if the relevant firmware .h files for the firmware would be generated / augmented as you propose. Such a mechanism would also greatly simplify my cloud builder implementation. However, I don't really understand what this, the term "upload" and the cloud builder has got to do with the Docker image. Can you please clarify that?

The Docker image and the cloud builder have got nothing to do with each other (i.e. they're not dependent on each other). And you're right, I won't allow uploading a config file through the cloud builder UI. It would IMO also defeat its purpose to a certain extent. It's got a graphical UI to lower the barrier for novices as much as possible. I believe those who feel comfortable enough tinkering with config files might as well use the Docker image. As I said, it'd be great if those building the firmware themselves (NodeMCU collaborators / contributors and others) could configure it in a more concise way rather than editing several header files. However, it would IMO be rather odd if such a comfortable mechanism were offered by a 3rd party Docker image instead of being built into the firmware build process itself.

Does that sound logical or is this a great misunderstanding?

TerryE commented 8 years ago

I don't really understand what t the cloud builder has got to do with the Docker image.

Sorry, but I get that I am talking at cross purposes by posting this issue here. I though that this was your custom build repo, but on a second look I am still confused as you have this docker-nodemcu-build repo, a nodemcu-custom-build repo which seems to be about tricking TravisCI to do the actual cloud build, and a closed source GUI hosted on frightannic.

In our previous discussion about using this sort of scripting tool, Cloud builder runs on a preconfigured Ubuntu docker image, and your reason for not wanting a Lua-based script was that this preconfigured image supported perl, python, and bash as standard but not Lua, so it would be a lot more convenient to script in one of these rather than have to install lua, lua-rocks and lua-rocks lua-filesystem on each build. This applies both for the cloud build and a docker image for general use, but less so in this second case as no lua-51 and no lfs means no luac.cross which is a real loss.

I don't really understand the term "upload"

This was specifically in the context of cloud builder. The GUI is nice for newbies one the first few times through, so is essential, IMO. However

So you either need to significantly extend your GUI or allow an alternative way to configure your build. Let's say we have an intermediate config format such as the one than my generate_user_modules.lua script uses the when you do a GUI build simply display this cnf much as shown above or include it in the link email. If you allow a text box scren for input of a cnf as an alternative to filling out all of the GUI, then intermediate users can just paste in there last cnf and optionally add such lines as

bit_rate         = 115200
gpio_interrupt   = enable
marcelstoer commented 8 years ago

Sorry for the confusion Terry. True, the cloud builder uses Travis - which (the way it and NodeMCU use it) itself is based on Docker images. I guess this was the missing link.

... tricking TravisCI to do the actual cloud build

You may call this "tricking", which has a very negative connotation for me, but yes, that's how it works. I simply want to ensure that the cloud builder is as close to the NodeMCU CI build as possible.

... Cloud builder...

... and NodeMCU CI build ...

... runs on a preconfigured Ubuntu docker image, and your reason for not wanting a Lua-based script was that this preconfigured image supported perl, python, and bash as standard but not Lua

Yes, you're right and my preference hasn't changed :wink:

Your comments about the shortcomings of the cloud build are valid in itself but they don't seem to be relevant for the target audience. I'm not Apple, so I don't claim to know upfront what my users need or want. That's why I keep statistics. 11k users have built 22k firmware images in the past ten months. I got less than 20 feature requests and bug reports so far. Adding the debug option was one of them believe it or not. Adding bit rate selection was also mentioned a few times but those requesting it were ok when I told them the firmware default might sooner or later be changed to 115200. It seems to me the service has the right options for its intended target audience. I mention this to refute (hope that's the right word) your arguments.

I created this Docker image exactly because the cloud builder isn't for everyone - nor should it be. One size doesn't fit all. See my personal definition of target audiences on https://hub.docker.com/r/marcelstoer/nodemcu-build/.

So, to conclude... Yes, I'm all for introducing an intermediary config format but I'd prefer for it to not be dependent on Lua scripts and it should be done in the firmware project to have the strongest effect.

TerryE commented 8 years ago

Marcel, let's carry on this conversation if and when appropriate elsewhere. As I've said both on this thread and previously, I have offered to port this script to Perl or Python as I know both.

If the name for your service is NodeMCU CI build, then can I ask that you refer to it as this on your site and in the NodeMCU documentation. You usually refer to it as a a [Cloud Build Service](Cloud Build Service) hence cloud builder is a reasonable familiar abbreviation, whereas expecting your supporters to call it NodeMCU CI build would require some supernatural precognition on their part, and this is unreasonable.

In the programming world, trick has a slightly different connotation to colloquial English. I didn't intend it as negative and as you will see if you click on this Google link, I didn't see any negative ones listed. Let me rephrase