Skip to content
This repository has been archived by the owner on Jul 28, 2023. It is now read-only.

Make ignoring of file watching event actions configurable #39

Open
kewegner opened this issue Sep 20, 2019 · 1 comment
Open

Make ignoring of file watching event actions configurable #39

kewegner opened this issue Sep 20, 2019 · 1 comment
Labels
enhancement New feature or request priority/low Low impact issue

Comments

@kewegner
Copy link
Collaborator

In an earlier issue it was found it might be useful to ignore one of the six types of events, specifically DIR WRITE.

We could create additional APPSODY environment variables which allow our users to turn off any of the six actions for either FILES, DIRs or both

The six actions supported by the watcher include:

CREATE
WRITE
RENAME
MOVE
REMOVE
CHMOD

@kewegner kewegner changed the title Make ignoring of file watching event types configurable Make ignoring of file watching event actions configurable Sep 20, 2019
@kewegner
Copy link
Collaborator Author

kewegner commented Dec 3, 2019

These comments assume that directory events would be re-enabled. If not there is no need for the directory piece of this work.

First it must be noted no one has asked for this feature as of yet.

To approach the problem the following would need to be done.

Declare either a single variable or multiple variables in the Dockerfile-stack on two axis:
e.g.
APPSODY_FILE_CONTROLLER_ACTIONS=chmod,write,create,remove,rename, move
APPSODY_DIRECTORY_CONTROLLER_ACTIONS=chmod,write,create,remove,rename, move

-- we may need NONE as an option, and if both are none we might not want to enable the watcher.

The default would be that all actions are allowed for both if no variables are present,

The controller would then need to read in these environment variables.

The watcher could have a map for directory actions allowed and a map for file actions allowed.

The pollEvents loop would need to basically check:

  1. Is the current item a file or a directory.
  2. what is the action being performed and is it allowed for this type (file/directory).

The filter might need to be different in the sense that the action would need to be known, whereas today only the regex or type (file/directory) would need to be known.

If directory events are not needed, or the events are deemed to be the same for file and directory we could also investigate using the filterOps method on the watcher.

// FilterOps filters which event op types should be returned
// when an event occurs.
func (w *Watcher) FilterOps(ops ...Op) {

@kewegner kewegner added enhancement New feature or request priority/low Low impact issue labels Dec 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request priority/low Low impact issue
Projects
None yet
Development

No branches or pull requests

1 participant