Make our assets reproducible regardless of environment and compilation tine
The assets building phase can produce different content hashes regardless of environment and time when they were built. Due to delivering multiple packages and images from the same commit SHA we should be sure we have the same content hash every time we invoke the compilation phase.
For instance, here are two images with same yarn.lock
file and list of dependencies and the same source code:
dev.gitlab.org:5005/gitlab/omnibus-gitlab/gitlab-ee:14.5.202111151320-2153b254bc3.733f0be8b25
dev.gitlab.org:5005/gitlab/charts/components/images/gitlab-webservice-ee:14-5-202111151320-2153b254bc3
These two images have different content hashes for 4 files:
-
.sprockets-manifest-cab2353598fc425eaab979a5d4358239.json
vs.sprockets-manifest-c052939cfd194ef7603e300fbc6dde7d.json
-
webpack/commons-pages.subscriptions.buy_minutes-pages.subscriptions.buy_storage.d3d9038d.chunk.js
vswebpack/commons-pages.subscriptions.buy_minutes-pages.subscriptions.buy_storage.e2de8b85.chunk.js
-
webpack/init_hand_raise_lead_button.39eb5865.chunk.js
vswebpack/init_hand_raise_lead_button.a08a7e24.chunk.js
-
webpack/runtime.f038baf3.bundle.js
vswebpack/runtime.8b028f12.bundle.js
We know content hash changes under the following conditions:
- Any dependency change
- Any change in a file itself
- Any change in a linked file (module)
- Weak hash function in webpack 4 or bad dependency which forces the new hash each time we do a build.
This issue is intended to investigate the reason why the mentioned images have different content hashes.
Here are possible solutions:
- Migrate to webpack 5 for using the strong hash function.
- Migrate to esbuild which does not have such problems.
- Validate babel packages and their usage.