fly-apps / fly-apps/nix-base

Layers have unexpected dependencies on each other

Open
#22 0 comments 0 reactions 0 assignees View on GitHub
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.