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.
Closes #79
This PR implements the new
glob
recipe type, which takes a directory recipe and a list of patterns, and bakes to a new directory filtered down based on the list of patterns.Even though Brioche already uses
globset
for glob matching, I ended up using Wax to match glob patterns for theglob
recipe. This is becauseglobset
(and most other glob matching libraries) usestd::path::Path
somewhere in the pipeline, which might lead to different behavior depending on the host platform. On the other hand, Wax is meant to be portable across platforms, so it's a good fit for this use caseOne limitation around Wax is that the paths to match against must be
&str
s, which mean they must be valid UTF-8. Brioche currently doesn't enforce that filenames are UTF-8, so paths in artifacts are converted usingString::from_utf8_lossy
, which means that wildcards will even work with invalid UTF-8 sequences in paths (this also means a glob pattern can use the Unicode replacement character (�) to match an invalid UTF-8 byte)I also disallowed any glob patterns from containing
!
. As far as I can tell, Wax doesn't handle "negative patterns" natively, so I wanted to reserve!
in case we wanted to support gitignore-style syntax for excluding specific files in the future