#85 Optimizing Dockerfiles of analyzers at util/dockerfiles
Closed by athoscr. Opened by lucasandrade.
kiskadeemes/kiskadee 73-optimize-dockerfiles  into  master

Download 85.patch

Signed-off-by: Lucas Andrade lucasandradeunb@gmail.com
Signed-off-by: Fabio Teixeira fabio1079@gmail.com

Change the COPY line of all Dockerfiles to the penultimate line, because it is the last line possible for COPY command. At the end the images build got a little bit faster.

Is there any reason for removing this line here?

Also, did you guys consider keeping the ENTRYPOINT as the last line of the Dockerfile, for readability? What do you think about it? When I look at Dockerfiles, I always refer to the last line to see what the container will actually run (It's OK if you disagree, this is not a blocker).

We remove this line because when the Docker start to run it's already at the root path.

Sorry we did not thing about keep the ENTRYPOINT as the last line. I agree with you, is better for readability but since we are focused on optimization I believe the current file is a good solution. And this is a small Dockerfile, so anyone else who tries to read will have no problems to finding the entrypoint.

We remove this line because when the Docker start to run it's already at the root path.

Does it? shutil.unpack_archive just decompresses the sources, which are (99% of the time) a directory with the target source code.

Then, we end up with a container looking for a Makefile or a configure file in the tempdir where we extracted the source code. Note that removing that line does not help: we want to figure out the root path of the extracted directory and cd in there.

There was a change at some point where we stopped passing the uncompressed sources path to this containers (we used to do that in earlier version of kiskadee). Then, we forgot to change the container as well.

This is a bug and we should open another issue for that.

Sorry we did not thing about keep the ENTRYPOINT as the last line. I agree with you, is better for readability but since we are focused on optimization I believe the current file is a good solution. And this is a small Dockerfile, so anyone else who tries to read will have no problems to finding the entrypoint.

I would not trade the (very low) performance gain (on building a container in developing mode, which would be done once in a while) for readability. But that's up to you, as I said, not a blocker.

Does it? shutil.unpack_archive just decompresses the sources, which are (99% of the time) a directory with the target source code.

Unless I am missing something here, then please, point me there :)

So this line:

cd $1

Need to be in the file? Should I put it back?

So this line:
cd $1
Need to be in the file? Should I put it back?

We do need to cd into the project directory to run scan-build. The line must be changes: there is a bug there. But this change does not belong to this PR. We need another issue/commit for that.

tl;dr:
1) Do not apply changes to util/dockerfiles/clang-analyzer/docker-entrypoint.sh unless you fix the bug in there.

So I just checkout the file ?
util/dockerfiles/clang-analyzer/docker-entrypoint.sh

Yes. Against the current master branch. Also squash the commit on your PR so we can have a single commit.

I updated issue #51 with the cd $1 bug information. No need for a new issue.

rebased onto 8d423e19a827323e6dfc63ce92eb71b7c2301cee

Pull-Request has been closed by athoscr

Metadata