Layers have unexpected dependencies on each other
- Dominant language
- Nix
- Stars
- 22
- Forks
- 5
- PR merge metrics
- No merged PRs in 30d
Description
In the ideal scenario, all 6 of the standard Rails app derivations may be be updated independently and generate an independent Docker layer. These layers are:
1. Base layer (busybox, ca-certs, etc)
2. Additional system deps (ffmpeg, etc)
3. Runtime (ruby 3.1.1)
4. Rubygems
5. Compiled assets
6. Source code
Layer 6 will always change, so is ignored here. The goal is for cached layers 1-5 to remain cached in the Nix store and Docker unless an explicit request is made to skip caching.
Here's the observed behavior from tests:
**When changing a asset file in `app/assets`**
Layers 1-4 remain unchanged. The gem layer 4 gets completely rebuilt, though it's simply copying existing software in. Ideally, layer 4 would not need rebuilding.
**When adding a new gem**
Layers 1-3 remain unchanged. The gem layer is rebuilt, as expected, but so is the assets layer 5. Ideally, layer 5 would only be rebuilt when an asset changes.
**When adding or removing a system dependency**
Changing system deps forces the runtime #3 layer to rebuild. Layer 3 should be able to stay cached, though in practice this is not that big of a problem given its small size. Gems layer 4 also changes, but it's not clear why. It should also stay the same.
Interestingly, the asset layer 5 remains unchained in this scenario, as expected.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.