Problem
Currently input artifacts (local directories, git repositories, docker repositories) are identified only by how to access them in their respective address spaces. Local dir is identified by its local path; git repo by its git remote and ref; etc.
This poses a problem specifically for local directories, because it is common for a directory to be moved to a different path. Currently dagger cannot differentiate between a directory changing path, and a directory being destroyed. If a new directory is moved to the path of the old directory, dagger cannot differentiate those two directories either.
From a UX perspective, the most obvious consequence is that when a user moves a directory, any dagger deployment which references that local directory as an input artifact will stop working, with no useful clue as to why or how to fix it.
Proposed solution
There are various short-term stopgap solutions to the particular problem of moving local directories - but this issue does not address them. Rather it addresses a suitable long-term fix for both this particular UX issues, and other UX issues with the same root cause.
The proposed solution is to add an indirection between the deployment config on the one hand, and the local directory path on the other.
When a local directory is first used an input artifact, it gets assigned a globally unique artifact ID (uuid or similar). That ID is written to a file at a standard location within the directory - for example .dagger_artifact. From that point on, that directory always uses the same artifact ID. In the dagger state, input settings no longer reference a local path directly: they reference the artifact ID. The source of truth for mapping ID to directory is the contents of the directory itself: this way if the directory is moved, it retains the same artifact ID. Dagger may maintain an index in its state to speed up lookup; but the index is not the source of truth, just an optimization. If the index is lost, it can be reconstructed by scanning the user’s home directory.
Problem
Currently input artifacts (local directories, git repositories, docker repositories) are identified only by how to access them in their respective address spaces. Local dir is identified by its local path; git repo by its git remote and ref; etc.
This poses a problem specifically for local directories, because it is common for a directory to be moved to a different path. Currently dagger cannot differentiate between a directory changing path, and a directory being destroyed. If a new directory is moved to the path of the old directory, dagger cannot differentiate those two directories either.
From a UX perspective, the most obvious consequence is that when a user moves a directory, any dagger deployment which references that local directory as an input artifact will stop working, with no useful clue as to why or how to fix it.
Proposed solution
There are various short-term stopgap solutions to the particular problem of moving local directories - but this issue does not address them. Rather it addresses a suitable long-term fix for both this particular UX issues, and other UX issues with the same root cause.
The proposed solution is to add an indirection between the deployment config on the one hand, and the local directory path on the other.
When a local directory is first used an input artifact, it gets assigned a globally unique artifact ID (uuid or similar). That ID is written to a file at a standard location within the directory - for example
.dagger_artifact. From that point on, that directory always uses the same artifact ID. In the dagger state, input settings no longer reference a local path directly: they reference the artifact ID. The source of truth for mapping ID to directory is the contents of the directory itself: this way if the directory is moved, it retains the same artifact ID. Dagger may maintain an index in its state to speed up lookup; but the index is not the source of truth, just an optimization. If the index is lost, it can be reconstructed by scanning the user’s home directory.