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
Spiritually related to #2480. Earthly is amazing as it is but building interdependent software packages is still somewhat painful. To the best of my knowledge, when you have a complex target DAG you are forced to either:
linearize your DAG, which sacrifices modularity and breaks down when the thing doesn't look like a tree
craft COPY statements to pull the necessary artifacts from each dependency, which is brittle when you don't have total control over the layer content
have a function that implements each target so you can chain them freely through invocation, which requires some care with build contexts (and still gets messy when function+target pairs are split across local and remote Earthfiles using COPYs)
Even if functions were meant to be the escape hatch, I believe first-class support for complex target DAGs would be a great feature. And since Buildkit supports merge and diff operations already, I imagine a MERGE statement for targets wouldn't be far fetched.
Note: In all honesty, this isn't as much of a proposal as it is a question. I see COPYs are merged copies (à la COPY --link), so I imagine this crossed your mind already and for some reason you discarded it. I wonder why.
Expected Behavior
Given the following Earthfile:
VERSION 0.8
foo:
RUN apt-get update && apt-get install -y foo
bar:
RUN apt-get update && apt-get install -y bar
baz:
MERGE +foo+bar SAVE IMAGE baz:latest
Run earthly +baz.
Confirm that baz:latest history shows both foo and bar.
MERGE could be a single llb.Merge operation or recursively expand to compute merge-diffs by interleaving llb.Diff and llb.Merge operations.
The text was updated successfully, but these errors were encountered:
Use case
Spiritually related to #2480. Earthly is amazing as it is but building interdependent software packages is still somewhat painful. To the best of my knowledge, when you have a complex target DAG you are forced to either:
Even if functions were meant to be the escape hatch, I believe first-class support for complex target DAGs would be a great feature. And since Buildkit supports merge and diff operations already, I imagine a
MERGE
statement for targets wouldn't be far fetched.Note: In all honesty, this isn't as much of a proposal as it is a question. I see
COPY
s are merged copies (à laCOPY --link
), so I imagine this crossed your mind already and for some reason you discarded it. I wonder why.Expected Behavior
Given the following Earthfile:
Run
earthly +baz
.Confirm that
baz:latest
history shows bothfoo
andbar
.MERGE
could be a singlellb.Merge
operation or recursively expand to compute merge-diffs by interleavingllb.Diff
andllb.Merge
operations.The text was updated successfully, but these errors were encountered: