I have an image that compiles a number of packages which takes quite a bit of time.
When I do git push resin master I just CTRL+C and let the built do it’s job up the coreos server.
I can see a few successful builds in the build log, but my devices does not download those updates.
What’s wrong?
OS: Resin OS 2.0.0+rev3 (prod)
Device: Raspberry Pi 3
Because the git HEAD only updates after the push command completes, I have to push again after build finish.
This time it uses cache images and updates the git head, devices are now downloading.
So you can CTRL+C to skip the waiting, but remember to push again after build complete.
Yes, until your git push return a success, it won’t be pushed to your device. You might note that build logs are still in beta, these are some of the issues we are fixing. 
By the way, do you by any chance have ControlMaster in your SSH config?
I would also say, that you should not rely on this “bug” to skip the waiting, as it is unlikely that the behaviour will stay like this. Most definitely users generally don’t want a CTRL-C interrupted build to be deployed to their fleet, and the service don’t want to build more than it has to.
The build process is gutenprint and it generally takes 2 hours up there.
I am using a notebook so I am imagining if there are ways to detach/reattach.
I have no experience in ControlMaster, with a bit of googling seems like what I want but I don’t know how to use it exactly.
AFAIK ControlMaster auto and ControlPersist of something is what I need, but how to reattach the build session from git push resin master?
Hey, yeah, long builds take long time unfortunately. We have some stuff in development that should help with that (faster builds), will keep you posted!
And no, the ControlMaster question was for debugging, that would actually not help you (it was for triaging some strange behaviour we’ve seen with connections to the builder, and wanted to check), and should not rely on disconnecting from the builder and reconnecting!
Another thing that’s coming out soon is building containers locally, and just pushing those through the system, it should also help you with the time, imho.
BTW, out of curiosity, what is the reason that you are building gutenprint? (instead of installing from repos) We are always interested in what kind of projects people do and how.
The Raspberry Pis are printing photos, and one of the printer support is still in experimental stage. We have to build that from source for a few PPDs.
In fact, we have already built a working image from buildpack-deps:jessie.
Just only if we can push that image …
It feels like the current build log watches stderr for the failure status.
My two cents: watch for exit code instead, because compilation usually throws loads of warnings…
The build makes sense! 
(and also sounds like a sweet project)
Can you give a bit more info on the stderr comment. Though I just tried with a quick example project, and just printing to stderr does not make the compilation stop, IMHO it should be watching the error codes indeed. Where have you seen that writing to stderr stops the compilation, have any more info about that? 
BTW, here’s my example Dockerfile to test:
FROM resin/raspberrypi3-debian
RUN >&1 echo "this is an info on stdout"
RUN >&2 echo "this is an error on stderr"
CMD while : ; do echo "Idling"; sleep 60; done
This builds all the way just fine. 
x x x
That wish might be satisfied sooner than you think. The resin command line tool just recently got a new capability to locally build a container and deploy onto resin without involving the builders. Check the resin build and resin deploy in the latest resin-cli version:
It’s brand new stuff, so still in testing, any feedback is appreciated.
