posita
commented
9 years ago One portable alternative that comes to mind is providing a Dockerfile defining a build environment and a CMD for producing a build (e.g.) in /tmp/build. Then anyone could make one by doing (e.g.):
docker run ... -v /tmp/build /host/path/for/build ... [IMAGE]The Dockerfile would not only be repeatably "executable" to make builds, but it would serve as documentation for the process as well.
If you're unfamiliar, Docker Hub has a base image for Centos. A Dockerfile for this project might look like:
FROM centos:5
# Download and install any required packages and sources, copy any build files, etc.
COPY ...
RUN ...
# E.G.:
RUN [ -f /tmp/pypy-2.5.1-src.tar.bz2 ] \
|| ( curl -o /tmp/.pypy-2.5.1-src.tar.bz2 https://bitbucket.org/pypy/pypy/downloads/pypy-2.5.1-src.tar.bz2 \
&& mv /tmp/.pypy-2.5.1-src.tar.bz2 pypy-2.5.1-src.tar.bz2 )
RUN [ "$( openssl dgst -r -sha256 /tmp/pypy-2.5.1-src.tar.bz2 | awk '{ print($1); }' )" = ddb3a580b1ee99c5a699172d74be91c36dda9a38946d4731d8c6a63120a3ba2a ]
# Check to make sure the user has mapped the target directory to a host directory
RUN [ -d /tmp/build ]
# Build command (run with `docker run ...`):
CMD ... && mv .../pypy-2.5.1-1-linux_x86_64-portable.tar.bz2 /tmp/buildOne alternate approach might be to put your image/environment setup commands in bootstrap.sh and your build command(s) in build.sh, which could reduce your Dockerfile to something like:
FROM centos:5
COPY bootstrap.sh /tmp/ # trailing slashes are required to indicate target is directory
RUN /tmp/bootstrap.sh
COPY build.sh /tmp/
CMD /tmp/build.shWith this approach, I find it convenient to do set -e (or equivalent) inside my .sh files, so that they'll error out on the first problem. set -x is also helpful to see where they're failing.
Again, if you're unfamiliar with Docker, it's generally good practice to ensure that environment/image setup (i.e., whatever lives in bootstrap.sh) is idempotent (i.e., if it was successfully run once, running it again doesn't further change the environment). My example fetching pypy sources above should meet this requirement (i.e., no file system changes are made if pypy-2.5.1-src.tar.bz2 was already successfully fetched).
Because there can be only one CMD in a Dockerfile, you would likely have to have different one for each version (e.g., pypy, pypy3, etc.). One possibility is to have separate build scripts and Dockerfiles (e.g.):
% ls
Dockerfile.pypy # (new)
Dockerfile.pypy3 # (new)
PLAN
README.rst
_tkinter_app.py.patch
bootstrap.sh # (new)
build-pypy.sh # (new)
build-pypy3.sh # (new)
drive.py
make_portable
translatenpoweroff
version.py
virtualenv-pypy% tail -2 Dockerfile.pypy
COPY build-pypy.sh /tmp/
CMD /tmp/build-pypy.sh% tail -2 Dockerfile.pypy3
COPY build-pypy3.sh /tmp/
CMD /tmp/build-pypy3.shThen you can specify which Dockerfile to use with the -f option to docker build (e.g.):
docker build ... -f Dockerfile.pypy ...Feel free to ignore any/all of the above without hurting my feelings. :relaxed: If you didn't already guess, I've been playing around with Docker a lot lately. I noticed you maintain fairly specific build environment requirements (Centos 5, proot, etc.). Docker provides a convenient way to declare and maintain those specs, while allowing others to conveniently perform builds as well. :grin:
squeaky-pl
techdragon
It's not clear how the weekly or release builds are made. The "How it is done" section is not specific enough for repeatable results.