This is a 3-parter.
a) Update the Documentation.
The offending page is here: https://pipelight.dev/guide/triggers/definition.html
It mentions first Git-Hooks, then the Watcher, and then it gives Examples which all relate to git-hooks.
This creates confusion, as in the reader's mind the Watcher gets associated with the examples.
Please move the Watcher section to the top of the page, so that it's Watcher, Git-Hooks, Examples.
b) Update the Config File.
Same place, the watcher config is called .pipelight_ignore, but it has both include and exclude mechanisms. So how does this work? Does the watcher watch everything by default? Nothing by default? If the file works the way I think it does, shouldn't it rather be called .pipelight_watcher? I must admit this is confusing, and I would have to mess around with the feature in order to understand it.
Finally, this config file is automatically created on pipelight init, whether the watcher is enabled or not. I'd rather not have this extra file in my repo if can be avoided. Why not create it on watcher enable instead?
c) Invert the Watcher Mechanism.
The file-watcher mechanism currently works on an exclude basis. Users must populate their .pipelight_ignore file with their .git folder and any other paths they do not want pipelines to automatically run, immediately, on any change.
"automatically run, immediately, on any change", that is a narrow application, and I am confident that for users who enable this feature, more filepaths will be excluded than included.
As such I propose to invert the mechanism, where instead of an exclude/ignore, the Watcher would work through an include mechanism instead, where .pipelight_watch would contain the paths to explicitly filewatch, instead of those to explicitly not-watch.
EDIT: this here is not documented. Please document: #17 (comment)
This is a 3-parter.
a) Update the Documentation.
The offending page is here: https://pipelight.dev/guide/triggers/definition.html
It mentions first Git-Hooks, then the Watcher, and then it gives Examples which all relate to git-hooks.
This creates confusion, as in the reader's mind the Watcher gets associated with the examples.
Please move the Watcher section to the top of the page, so that it's Watcher, Git-Hooks, Examples.
b) Update the Config File.
Same place, the watcher config is called
.pipelight_ignore, but it has both include and exclude mechanisms. So how does this work? Does the watcher watch everything by default? Nothing by default? If the file works the way I think it does, shouldn't it rather be called.pipelight_watcher? I must admit this is confusing, and I would have to mess around with the feature in order to understand it.Finally, this config file is automatically created on pipelight init, whether the watcher is enabled or not. I'd rather not have this extra file in my repo if can be avoided. Why not create it on watcher enable instead?
c) Invert the Watcher Mechanism.
The file-watcher mechanism currently works on an exclude basis. Users must populate their
.pipelight_ignorefile with their.gitfolder and any other paths they do not want pipelines to automatically run, immediately, on any change."automatically run, immediately, on any change", that is a narrow application, and I am confident that for users who enable this feature, more filepaths will be excluded than included.
As such I propose to invert the mechanism, where instead of an exclude/ignore, the Watcher would work through an include mechanism instead, where
.pipelight_watchwould contain the paths to explicitly filewatch, instead of those to explicitly not-watch.EDIT: this here is not documented. Please document: #17 (comment)