Open christophermaier opened 6 years ago
Would we prefer to make everything explicit, or would an implicit (but overridable) policy of never triggering for changes to certain globs such as *.md
be good?
I figure that might avoid a lot of unnecessary work without requiring as much configuration effort for each builder package.
I think it's a little bit too "magic" that somebody would need to know what the default whitelist is. I wouldn't want to be on the receiving end of trying to debug a build that isn't triggering because content that is inlined into my code but stored as an .md
.
It'd be perfectly reasonable to include a default whitelist in a generated .bldr.toml
for somebody, though!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.
Currently, you can specify fileglobs in
.bldr.toml
what determine when to trigger a build; if a changed file matches the glob, build.Sometimes, though, it can be useful to specify the inverse. A commit that consists of only a
README
change, for example, shouldn't be creating a new package.We should have a way to express this in
.bldr.toml