![]() |
Nuke.Cola
|
There are cases when one project needs to compose from one pre-existing rigid folder structure of one dependency to another rigid folder structure of the current project. For scenarios like this Nuke.Cola provides ImportFolder build class extension method which will copy/link the target folder and its contents according to some instructions expressed by either a YAML manifest file (by default export.yml) in the imported folder or provided explicitly to the ImportFolder extension method.
For example the following target:
will process/import the file/folder structure on the left to the file/folder structure on the right.
export.yml files which content is not explicitly spelled out here, and is discussed further below.To break it down:
A regular folder (like Unassuming) with no extra import instructions provided will be just symlinked.
Optionally folders and files containing a preset suffix (for example and by default Origin with either _, . and : as separators) can be replaced by another suffix chosen by the importing script (in this case Test). Files/Folders linked or copied will have this suffix replaced at their destination. (see FolderOnly_Origin -> FolderOnly_Test). If Suffixes were not specified in ImportOptions or if ImportOptions is not provided at all, suffix processing is skipped.
Folders can dictate the intricacies of how they're shared this way with a simple YAML manifest file (by default called export.yml but this can be changed). For example the one in Both_Test does
Linking folders is straightforward and globbable. If suffixes are provided target folders and parent folders (up until export root) is processed for suffixes at destination same as when copying folders.
When linking files, globbed files are individually symlinked, optionally with suffix processing on file/folder name.
Copying folders recursively have the same folder name processing but doesn't touch its contents (not even file/folder name processing)
When copying files (including when they're globbed) their content can be also processed for suffixes if procContent is set to true and suffixes are enabled. Copying an entire folder recursively but with all the file/folder names processed can be done by simply doing recursive globbing -file: "MyFolder/**". The reasoning behind this design is suggesting performance implications, that each file is individually treated.
The destination relative path and name can also be overridden with as:. This works with globbing as well where the captures of * and ** can be referred to as $N where N is the 1 based index of the wildcards. For example
Where all the files inside the recursive structure of subfolder Flatten is copied/linked into a single-level subfolder. $2 in as: indicates it uses the second wildcard (the one at *.txt).
Export manifests can reference other export manifests when they're listed under use key the same way as copies or links are done, for example:
This feature is not visualized above in the folder structure figure as that's already complicated enough. Note that copy and link will not consider instructions from export manifest files, only use does that, and use will ignore every folder which doesn't have an export manifest file directly in it. This is done this way to alleviate surprises from "smart defaults".
There are cases when it's easier to have an explicit rule for ignoring files/folders from a generic match, instead of composing a match for wide range of files, but the ones we want to exclude. For this reason folder composition allows to list patterns which will exclude matched paths. They can be declared for all the exported folder, or individual glob items.
.gitignore are not considered, but in the future there may be a feature which ignores files the way git does with .gitignore upon request. Until that time copying entries from your gitignore to not: fields as an array should do the same, if that is indeed the preferred behavior.* in YAML has special meaning. Therefore string values containing * needs to be single or double quoted. Therefore