A common use for build containers is to build a version that is already checked out, and do so in the host directory so that the results are immediately available. Since the contents of the container are not needed, one would use an ephemeral container that acts as a single command, such as:
docker run -it --rm -v$PWD:/aseba deb
This would compile the current source code in a controlled environment, leave the .deb file in the host directory, and discard the container.
If it were desirable to keep the object files, one could reserve an environment variable for the build directory, permitting:
docker run -it --rm -v$PWD:/aseba -e BUILD=./build deb
Proposed changes to build.sh:
[ ] If the current directory already contains Aseba source code, don't do a git clone
[ ] If a BUILD directory is specified in the environment, use it, otherwise build in a temporary directory
Without -v ou -e arguments, the container will continue the previous behavior, cloning a fresh copy of the Aseba source code in /aseba and building in there.
A common use for build containers is to build a version that is already checked out, and do so in the host directory so that the results are immediately available. Since the contents of the container are not needed, one would use an ephemeral container that acts as a single command, such as:
This would compile the current source code in a controlled environment, leave the .deb file in the host directory, and discard the container.
If it were desirable to keep the object files, one could reserve an environment variable for the build directory, permitting:
Proposed changes to
build.sh:git cloneWithout
-vou-earguments, the container will continue the previous behavior, cloning a fresh copy of the Aseba source code in/asebaand building in there.