load: include details about included files on Project#444
Merged
milas merged 1 commit intocompose-spec:masterfrom Aug 18, 2023
Merged
load: include details about included files on Project#444milas merged 1 commit intocompose-spec:masterfrom
Project#444milas merged 1 commit intocompose-spec:masterfrom
Conversation
Add a map to `Project` that has Compose YAML filename as key and
any `IncludeConfig`s loaded from it.
This is populated as the project is recursively loaded.
For example:
```
proj/
compose.yaml
a/
compose.yaml
b/
compose.yaml
```
If `project/compose.yaml` has:
```
include: ['./a/compose.yaml']
```
And `project/a/compose.yaml` has:
```
include: ['../b/compose.yaml']
```
The final result after load is conceptually:
```
{
"proj/compose.yaml": ["proj/a/compose.yaml"],
"proj/a/compose.yaml": ["proj/b/compose.yaml"],
}
```
(Note: in reality, it's a list of `IncludeConfig`, which has multiple
fields. Example is simplified.)
Relative path resolution is based on overall loader configuration,
but note that disabling it does not work properly for `include`
currently due to other issues.
This makes it possible for the caller to understand a bit more
about the loaded project resources. We're really overdue for a bit
of an overhaul/refactor of the loader - at that point, I think it
might be better to have a `Loader` object type that can track stuff
like this on the instance because it's weirdly both part of the
project and NOT part of the project at the moment (similar to
`Profiles`, project name, etc).
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
07c0fc1 to
1af5178
Compare
ndeloof
approved these changes
Aug 18, 2023
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Add a map to
Projectthat has Compose YAML filename as key and anyIncludeConfigs loaded from it.This is populated as the project is recursively loaded.
For example:
If
project/compose.yamlhas:And
project/a/compose.yamlhas:The final result after load is conceptually:
{ "proj/compose.yaml": ["proj/a/compose.yaml"], "proj/a/compose.yaml": ["proj/b/compose.yaml"], }(Note: in reality, it's a list of
IncludeConfig, which has multiple fields. Example is simplified.)Relative path resolution is based on overall loader configuration, but note that disabling it does not work properly for
includecurrently due to other issues.This makes it possible for the caller to understand a bit more about the loaded project resources. We're really overdue for a bit of an overhaul/refactor of the loader - at that point, I think it might be better to have a
Loaderobject type that can track stuff like this on the instance because it's weirdly both part of the project and NOT part of the project at the moment (similar toProfiles, project name, etc).