loader: report project structure #459
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With
include
'd Compose files, it's important to know the origin of each service to be able to properly resolve paths to them, for example.A new
FileMeta
field on theProject
type provides detailed access to the underlying file structure/hierarchy.This replaces
IncludeReferences
andComposeFiles
, which were inconsistent and not comprehensive.What Problem Does This Solve
In Compose itself, when we use
x-
fields for non-stable features, the "load" logic lives in thedocker/compose
codebase until stabilized.That means it needs to resolve in relative paths there --
compose-go
can't help because it doesn't know about the fields to begin with. However, if they came from an included file,IncludeReferences
has theProjectDirectory
BUT there's no way to know where a service came from! TheFileMeta
tree combinesComposeFiles
+IncludeReferences
and, critically, additionally populates service back-references.