Revert "use a script instead of piping to stdin in run_docker_build"

[isuruf]

Reverts #337

[jakirkham]

Are you ok with us reverting this for now @minrk? Again I do want us to tackle this and think we are substantially closer than before. Just want us to get the conda-smithy 3 release out ASAP.

[isuruf]

Didn't see your message @jakirkham. We can tackle this later

[jakirkham]

No worries. Just wanted to make sure everyone is onboard. :)

Might play with this a little later. Have some ideas on how we can get @minrk's strategy to work.

[isuruf]

Btw, if we do docker run -e BINSTAR_TOKEN value of the env variable is taken from the env. So no need to use a env-file.

[jakirkham]

The issue is that might get echoed in the log with set -x. CIs sometimes add this under the hood and it is easy to get bitten by a well intentioned set -x landing in the wrong place relative to some secret. So the env file is preferable. That said, I think we can still use env file with docker run. So it should be simple to adapt.

We can revisit though after the last piece is in. ;)

[minrk]

Yeah, no problem. The O_NONBLOCK issue in mpich that prompted most of these issues may be fixed in the latest mpich-3.2.1 (there is a patch that unsets O_NONBLOCK after completion, it's unclear if that fixes the pipe problem).

I still think this is the right thing to do. I didn't know about -e KEY pulling from the env. That's better than the env-file. I can re-issue the previous PR with that, using docker run since there's no longer a reason to do create & start in two steps. No pressure getting it into 3.0! The CB3 stuff is way more important than this one issue that only seems to affect mpich-derived packages. FWIW, with #692, this was working just fine as-is, so I think it should be fine.

[minrk]

Reissued #337 as #701 with docker run -e BINSTAR_TOKEN. No need to get this into the 3.0 release, though! Review/test at your leisure.