zncdatadev / containers

Container for images of the Kubedoop Data Platform
Apache License 2.0
3 stars 4 forks source link

[Draft]: add test logic for the docker build process #76

Open whg517 opened 2 months ago

whg517 commented 2 months ago

example

FROM rockylinux/rockylinux:9

RUN touch /tmp/foo.txt

# check if the file exists
# test: RUN test -f /tmp/foo.txt
.PHONY:
test:
    grep -v '^# test:' Dockerfile > Dockerfile.test
    $(CONTAINER_TOOL) build -t example.com/foo:latest -f Dockerfile.test .
    rm -f Dockerfile.test

explain

Check that the previous build meets expectations by adding some RUN instructions to the dockerfile that you need to test. In order not to affect the production image, pass the test instructions through the # test: comment. Remove the # test: tag with the command before the test is executed, and then use the temporary test dockerfile. Build the image directly during the build phase without worrying about the annotated test instructions. On the other hand, it also has a certain role for developers.

pros

cons

If you consider not disassembling the existing RUN instruction, you can add build-args to pass a TEST=true environment variable when testing, and judge and test in the shell logic of the existing RUN instruction. However, this will increase the complexity of the RUN instruction and increase the development cost.

On the issue of the number of layers of dockerfile, in the early docker practice, it was proposed to minimize the number of layers, and there are some views on the concept of not exceeding many layers. But that's rarely seen now. By using the cloud-native build tool buildpacks, we can see that in order to maximize the reuse of the container system, each layer will be very small, and the final number of layers of the image is very large, of course, we can also see that the number of building layers of some mainstream images reaches more than 10 layers.

whg517 commented 2 months ago

@lwpk110 @tutunannan please review