Configure fswatch locally

[nikdragovic]

Determine what is being looked for (deletes, renames, moves), set up for multiple environments. Each domain should have its own index.

[laurenhamel]

I'm adding this issue as blocked by #33 because we'll want to complete that test and compare its benchmarking results to #34 before making a decision in regards to how we wish to proceed.

[laurenhamel]

Locally, in terms of development, I'm thinking we could leverage grunt's watch task to implement fswatch-like behavior and trigger re-indexing. This will allow us to get off the ground quicker during development, but we will still want to test out fswatch, especially in terms of how its configured, in preparation for setup on the server environment.

[laurenhamel]

I successfully setup fswatch on my local machine and went ahead and wrote a pair of bash scripts for configuration. I'm copying over the message I left in my last commit here, which should help detail what I put in place:

---

This adds two bash scripts to help with configuring and running fswatch on the server:

• The watch script configures and starts a series of fswatch tasks in the background and subsequently calls the index script each time a file change is detected. Changes to the templating engine's engine/ and/or patterns/ folder will trigger a reindexing of all sites whereas changes specific to a site's domain root folder (e.g., libraries.emory.edu/) and/or data/ folder with only trigger a reindexing for the given site.

• The index script neatly handles the reindexing of one or more sites based on the level at which a file change was detected. That is, if an environment-level file change was detected, it will compile a list of all available sites and force a reindexing for each one. Otherwise, if a site-level file change was detected, it will only force a reindexing of the given site.

One thing to note is that the watch script will need to be updated to register new domains as additional sites go live. In terms of setup on the server, though, this now allows us to simply execute our watch script one time via a shell at the server's root to properly configure a collection of fswatch tasks across all sites and environments.

---

@kristianserrano, can you test this out and make sure it's also working for you? Here's some steps for testing:

1. Git clone a copy of the feature/fswatch-config branch

2. Make sure all dependencies are up-to-date:

   npm install && composer install

3. Build the templating engine either via grunt build or grunt dev

4. Install fswatch on your system via Homebrew:

   brew install fswatch

5. In a command terminal at the root of the project, run the watch script:

   bin/watch -d -u=<INDEX_USERNAME> -p=<INDEX_PASSWORD> -c=prerender

   -d - enables development mode -u - the username you've set for the index process in your .env file -p - the password you've set for the index process in your .env file -c - an optional callback for the index process

6. Test the fswatch task by modifying a file:

   • If you used grunt build, edit a file in the public/ folder
   • If you used grunt dev, edit a file in the src/ folder and wait for the grunt task to finish recompiling the public/ folder

7. If all goes correctly, fswatch should pick up the change and log the index process' output to the same terminal window where you ran the watch executable.

8. When done, to kill the background fswatch processes, run the following in a command terminal:

   pkill -f EUL-fswatch

   The background fswatch tasks have been aliased within a custom EUL-fswatch name for easy cleanup and restart as needed. This will also help us not interfere with any other fswatch tasks that may be running once we get into a live server environment.

[kristianserrano]

It worked, @laurenhamel !

[laurenhamel]

I'm moving this back to "In Progress" since some changes will need to be made either to the watch executable or the indexing process per our conversations on Friday. To recap here, we'll need to add in a flag of some sort to prevent reindexing from being triggered more than once due to the server architecture.

[laurenhamel]

Moving this into Sprint 10.

[libdgg]

@kristianserrano @laurenhamel per our standup decision on 5/30 to implement the manual trigger I'm moving this issue to Sprint 15 to revisit this topic and a long term solution at a later date.

[laurenhamel]

This is no longer relevant as the templating engine is being decommissioned for Phase 2.