-
Notifications
You must be signed in to change notification settings - Fork 57
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
Docker-ising the build process #22
Comments
So i've been learning Docker recently and it might be possible to take advantage of this to automate this entire process. Are all your scripts up on github? If so when i have some time ill get started on making a Docker image to add on, this should allow you to pull the image and build the STLs trivially, likely can hook it up to Docker-hub to have automatic builds as well. |
Thanks! That sounds like exactly what I want to do... My "scripts" are up, such as they are. They need a lot of improvement, but for the moment I have a batch file that runs on my Windows machine and compiles the larger STL files (the link below has the main body commented out, which should probably be undone, but you'll get the idea): https://github.com/rwb27/openflexure_microscope/blob/master/rebuild_illumination.bat I originally tried with Python, but couldn't get it to work, OpenSCAD just wouldn't function correctly in a subprocess. If you can run OpenSCAD in your docker image from a bash script or something, that would be an enormous help - just pasting in the command line options from the script above would be a perfectly good test case. |
In f805e5e I've now got batch files for everything bar the illumination and lens insertion tools. This is progress! It would be nice to use something like make rather than just a bunch of batch files, and I'm starting to understand how to do that (I've not used make before for this). It should still be windows-compatible, because you can use make in MSYS, which comes bundled with Git for Windows. Other options do exist as well... |
Hey, |
Sure. The scripts are very (painfully) simple. Essentially, you can build each STL file by compiling one OpenSCAD file, either by opening it in OpenSCAD and hitting "compile" or by running the OpenSCAD binary in command-line mode. The commands to compile all the relevant bits are listed in the batch files: they are in the root directory of the repository. The same commands should work as-is on Linux, provided you change the (currently hard-coded, sorry) OpenSCAD binary path to point it to the right place. There's some documentation on (using OpenSCAD from the command line)[https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Using_OpenSCAD_in_a_command_line_environment] though to be honest I'm not sure you even really need to read it in order to build things. It does however mention some examples of invoking it from If the only options you give to openscad are an output file ( NB compiling I believe the only dependency it has is on OpenSCAD, which is available on Linux (though I'm ashamed to say I've yet to use it on that platform). I hope that works - do please give me a shout if any of those instructions are lacking! |
Sweet! ill start playing around w/ first dockarizing and running OpenSCAD, i'll likely expose a jupyter notebook from within the docker, so you can go to a browser window and compile everything from there (including selecting version etc). |
cool :) does that mean you'd anticipate building stuff from a Python script? I played around with that briefly (there's some py files in the repository) but never got it to work, that may be a Windows thing though, I think it just didn't like being run in a subprocess. Picking versions/options in a browser would be really nice. I have been thinking a bit more about make, and it quite probably is the right way to do things - I guess whatever interface does the building with OpenSCAD could just as easily run make. My thought was that each version of the microscope could be a target (versions just being particular combinations of variables). That target would then simply re-run make with said variables defined, which would then compile whatever's needed and copy it into the destination folder. I think it would even be possible to be cunning, and get make to cache the files that don't depend on particular variables (e.g. the gears are the same for all the versions). However, if you can get OpenSCAD working in docker, I can sort out the makefile! |
OK, so I've had a stab at a makefile in 9e44382 and it now works, at least as well as the old batch files did (in that it can now rebuild everything, with the exception of the optics modules). It's not beautiful, but you can now just "make all" and, provided openscad is in your path, it should work. Next step is probably to use variables in the makefile and/or create individual targets for the different microscope versions. |
Hey, Just wanted to say i've been working to dockerize this whole thing and i stumbled on: |
Thanks - I have been considering some more Python-based solutions, my problem so far is that OpenSCAD already puts a lot of people off; adding Python into the mix will likely make that issue worse... Also, my quick skim of the docs for SolidPython suggests that it's a Python wrapper for OpenSCAD - and importantly its output is OpenSCAD code, not STL files. So you still need a working OpenSCAD installation, and you'd just be calling it from Python. So I think SolidPython might offer a solution for e.g. the Optics module, where it's necessary to tweak the source code to compile different versions, but I don't think it simplifies compilation, as you still need to have the OpenSCAD binaries available in order to render STL files. Is there a reason that rebuilding through Jupyter is particularly advantageous vs just running make? I guess it gets a web interface that makes it easy to tweak parameters... |
So, the reason to rebuild through jupyter is that its trivial to start a Docker container that has Openscad installed in it (https://hub.docker.com/r/wtnb75/openscad/), the issue is interacting with it in a meaningful way. So I'm almost done writing, essentially a python wrapper that is run when the docker container starts, so you can rebuild by say, running "docker run -it open_flexure_container rebuild_microscope.py -v output_data:output_data --foot_height=30 ..." adding the other handful of parameters. This works and essentially is a one liner that spits out STL files in a specific folder "-v output_data:output_data" You can generate STL files quickly, but is more of a one-off and doesn't allow for editing. Instead, if the whole thing is inside a Jupyter notebook (running SolidPython code, essentially a translation of the current OpenScad code), it can be exposed through a server that the container is running, so you can edit and rebuild, spitting out the STL in the same folder "-v output_data:output_data". The perk of this is that it becomes insanely easy to change the entire microscope quickly, simply change code and hit shift+enter to run and spit out STL file. The reason why this actually increases the exposure is because once the docker container is set up, its a one line docker command to pull and run the image, followed by you simply going to say, http://localhost:8890 where you can edit and rebuild the microscrope trivially (into STL files which are output into that folder). https://hub.docker.com/r/jupyter/minimal-notebook/ i think is a decent example. Once I get the files building in the docker container i'll put it up on Dockerhub. The only issue with makefile is that its largely a static deployment strategy, which will take lots of upkeep and its editability (special knowledge required) will be low, although it can be run pretty much anywhere. |
OK, that makes a lot of sense. Currently all the makefile does is run a bunch of command-line OpenSCAD builds anyway, so that should be fine to do from a python script. The reason I've not done it from python so far is that it seems to crash on Windows, and I never figured out why - I guess Docker is designed to solve precisely this problem, making sure everyone has a consistent build environment. I don't currently see an automated way to get the OpenSCAD files translated into SolidPython, but I think it's easy enough to find a simpler way to do the necessary pre-processing on the source files using Python, and possibly switch to SolidPython in the future if that looks promising. If you can get iPython to build anything using OpenSCAD in a docker container, that's the hard part done as far as I'm concerned; I can knock up the scripts to wrangle the source files fairly easily I think. One last question, exposing my ignorance of Docker; how do you get files in and out of the container - will it be possible to automatically pull the source code in from the git repository, and spit out the STLs into a convenient build directory? I'll set it up and have a play, hopefully that will answer some of my questions! |
Hey, |
Great :) Each time OpenSCAD is run, it's only processing one file - the dependencies are there because the file uses "include" or "use" statements, which mean it depends on the files I've listed. My hope is that
You can probably guess that the -D lines are what set the OpenSCAD variables. This works nicely for everything except the optics modules (for which I'll need to preprocess the source file to some degree). |
Hey, Parser error in line 142: syntax error Parser error in line 150: syntax error I think the problem might be the version of Openscad i'm using, because of the linux distro i'm using only has Openscad 2014, are you using the later version? I'm actually running this all on the raspberry pi itself... I thought it would be a good idea, and kinda cool, if it can actually build itself type of deal. |
cool! That is indeed progress - but yes, I am using the latest version. I forget precisely what the changes were (around variables and things mostly) but I don't think it is trivial to make the files backwards-compatible... I now have Docker running though :) |
Hey, so attached is a Dockerfile i made which can be built and run for example like: docker build -t test_scad . Also I included a python script which can replace the jupyter command when you're ready to make the container completely headless (instead of interacting w/ it through http://localhost i set the password to "openflexure" as you can see in the dockerfile) that should help alot i think, i'll keep working on it soon |
Hey quick note, in the above zip file ignore the python script... i uploaded the wrong one, the dockerfile is definitely useful, but i'll upload a new python script soon |
Cool :) I've built it successfully so that all seems good - Unfortunately I'm going to have to wait for permission to run it, as I need a firewall rule to allow Docker to mount volumes - the joys of not being your own admin... Hopefully that will be sorted soon and I'll let you know how I get on :) |
Hello, |
ah, quick trick: will run an interactable (-i) bash prompt within the image which will disconnect when you do. Docker exec allows you to execute a command within a given running container, super useful |
Oh! don't forget, its actually quite easy to install Docker on a Mac or Windows machine too, in case you dont want to deal w/ firewalls and such and just want to run everything local |
Sure - I should just put it on my laptop; the problem is that my desktop (Windows machine) is so tightly managed, I can't connect to docker even when it's running on the same machine without special permission from IT which I've now obtained for some, but not all, ports. The command above does work though, so that is definitely progress! |
Success :) After much faffing about, I've succeeded in connecting to my Docker install. Turns out the missing link was forwarding a port from my host machine to the container (-p 127.0.0.1:8090:80) as Docker for Windows doesn't do this by default. Perhaps for you on Linux it's different... Anyway, I guess now the ball's in my court to knock up a python script to do the building :) |
Progress sincle I last updated here:
|
For my reference: while this repo is currently quite full of images, etc. it might be worth using a sparse checkout to download the SCAD files to the container - this will take an order of magnitude less time. |
I should mention that the way I manage mine is by using different branches and only pulling the one i need, its served me well so far but keep in mind i'm actually working on deploying all this in a Resin.io image (which this project definitely will be incorporated) |
I thought I'd add some comments in case they are helpful:
https://gist.github.com/rwb27/5ab632a2d5ddf0949b052d2fd8754690 |
It would be much better if the built STL files were automatically generated on each commit (or nightly, or some other schedule). I have a couple of batch files that do this presently, but it would be nice to go for something a bit more sophisticated (and cross-platform). If someone reading this knows about how to nicely automate builds with OpenSCAD, or how to integrate building with the GitHub API, I'd love to hear from you!
The text was updated successfully, but these errors were encountered: