You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As an Osmosis engineer, I would like to reduce image build times so that I don't waste time or focus on waiting for no reason.
This is a huge impediment to productivity where every time a developer makes a change to an image, they have to wait for around 4 minutes, and, as a result, lose the flow. The image build times should be minimized by structuring the steps and stages optimally and removing redundant steps.
Task 3.1 - Remove stale or redundant steps
Investigate all our images to remove stale or redundant steps that may have become such due to the repository evolving over time.
RUN sha256sum /lib/libwasmvm_muslc.aarch64.a | grep 7d2239e9f25e96d0d4daba982ce92367aacf0cbd95d2facb8442268f2b1cc1fc
RUN sha256sum /lib/libwasmvm_muslc.x86_64.a | grep f6282df732a13dec836cda1f399dd874b1e3163504dbd9607c6af915b2740479
We don't need to have ADD and RUN for both architectures in most Dockerfiles. Instead, we should provide architecture as an argument to the Dockerfile and only ADD and RUN wasm libraries for the desired one.
Task 3.2 - Leverage Build Cache
We should leverage build-cache by structuring the steps in each Dockerfile in such a fashion as so to minimize the rebuild frequency.
One example relevant to this issue is evident here:
RUN sha256sum /lib/libwasmvm_muslc.aarch64.a | grep 7d2239e9f25e96d0d4daba982ce92367aacf0cbd95d2facb8442268f2b1cc1fc
RUN sha256sum /lib/libwasmvm_muslc.x86_64.a | grep f6282df732a13dec836cda1f399dd874b1e3163504dbd9607c6af915b2740479
COPY directive requires updates much more frequently than the subsequent ADDs and RUNs. As a result, every time we make a change to the codebase and attempt to rebuild an image, it will redundantly repeat ADD and RUN steps simply because these are located after COPY
Background
This is a huge impediment to productivity where every time a developer makes a change to an image, they have to wait for around 4 minutes, and, as a result, lose the flow. The image build times should be minimized by structuring the steps and stages optimally and removing redundant steps.
Task 3.1 - Remove stale or redundant steps
Investigate all our images to remove stale or redundant steps that may have become such due to the repository evolving over time.
An example:
osmosis/tests/e2e/chain_init/chain-init.Dockerfile
Lines 17 to 20 in d5cd033
We don't need to have
ADD
andRUN
for both architectures in most Dockerfiles. Instead, we should provide architecture as an argument to the Dockerfile and onlyADD
andRUN
wasm libraries for the desired one.Task 3.2 - Leverage Build Cache
We should leverage build-cache by structuring the steps in each Dockerfile in such a fashion as so to minimize the rebuild frequency.
One example relevant to this issue is evident here:
osmosis/Dockerfile
Lines 17 to 23 in d5cd033
COPY
directive requires updates much more frequently than the subsequentADD
s andRUN
s. As a result, every time we make a change to the codebase and attempt to rebuild an image, it will redundantly repeatADD
andRUN
steps simply because these are located afterCOPY
Resources
Tip #1
: https://www.docker.com/blog/intro-guide-to-dockerfile-best-practices/Status
The text was updated successfully, but these errors were encountered: