Not implementable : this rule can reduce energy cost, but is hardly implementable with static analysis,
Rule title
Execute instructions in a specific order
Language and platform
Docker
Rule description
When building an image, Docker steps through the instructions in your Dockerfile, executing each in the order specified. For each instruction, Docker checks whether it can reuse the instruction from the build cache.
(https://docs.docker.com/develop/develop-images/guidelines/)
The following example shows a small Dockerfile for a program written in C.
FROM ubuntu:latest
RUN apt-get update && apt-get install -y build-essentials
COPY main.c Makefile /src/
WORKDIR /src/
RUN make build
Each instruction in this Dockerfile translates to a layer in your final image. You can think of image layers as a stack, with each layer adding more content on top of the layers that came before it:
Whenever a layer changes, that layer will need to be re-built. For example, suppose you make a change to your program in the main.c file. After this change, the COPY command will have to run again in order for those changes to appear in the image. In other words, Docker will invalidate the cache for this layer.
If a layer changes, all other layers that come after it are also affected. When the layer with the COPYcommand gets invalidated, all layers that follow will need to run again, too:
In this example, we’ll prefer to run “WORKDIR” Before “COPY” because we don’t need to do the command another time when there is a modification in “main.c”:
Rule short description
Write instructions in a correct sequence to maximize cache usage when rebuilding after a modification.
Rule justification
Using Docker cache can reduce :
Network connectivity, for example with RUN that pull informations from the web
Ressources, avoiding recreating existing layer
We can wondering if this issue is relevant, because in real life example, Docker image are build with pipelines, and the Docker cache is not always keep between build.
Severity / Remediation Cost
Severity : Minor, energy will be consumed only at build time.
Remediation cost : Easy, users will need to reorganize Dockerfile instructions.
Implementation principle
Not implementable in Sonarqube, because it will depend for each Dockerfile, there is no common mistake to check.
(Existing rule in draft : https://github.com/green-code-initiative/ecoCode-common/issues/42)
Not implementable : this rule can reduce energy cost, but is hardly implementable with static analysis,
Rule title
Execute instructions in a specific order
Language and platform
Docker
Rule description
When building an image, Docker steps through the instructions in your Dockerfile, executing each in the order specified. For each instruction, Docker checks whether it can reuse the instruction from the build cache. (https://docs.docker.com/develop/develop-images/guidelines/)
The following example shows a small Dockerfile for a program written in C.
Each instruction in this Dockerfile translates to a layer in your final image. You can think of image layers as a stack, with each layer adding more content on top of the layers that came before it:
Whenever a layer changes, that layer will need to be re-built. For example, suppose you make a change to your program in the main.c file. After this change, the COPY command will have to run again in order for those changes to appear in the image. In other words, Docker will invalidate the cache for this layer. If a layer changes, all other layers that come after it are also affected. When the layer with the COPYcommand gets invalidated, all layers that follow will need to run again, too:
https://docs.docker.com/build/cache/
In this example, we’ll prefer to run “WORKDIR” Before “COPY” because we don’t need to do the command another time when there is a modification in “main.c”:
Rule short description
Write instructions in a correct sequence to maximize cache usage when rebuilding after a modification.
Rule justification
Using Docker cache can reduce :
We can wondering if this issue is relevant, because in real life example, Docker image are build with pipelines, and the Docker cache is not always keep between build.
Severity / Remediation Cost
Severity : Minor, energy will be consumed only at build time.
Remediation cost : Easy, users will need to reorganize Dockerfile instructions.
Implementation principle
Not implementable in Sonarqube, because it will depend for each Dockerfile, there is no common mistake to check.