Closed nikdragovic closed 4 years ago
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.
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.
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:
Git clone a copy of the feature/fswatch-config
branch
Make sure all dependencies are up-to-date:
npm install && composer install
Build the templating engine either via grunt build
or grunt dev
Install fswatch
on your system via Homebrew:
brew install fswatch
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
Test the fswatch
task by modifying a file:
grunt build
, edit a file in the public/
foldergrunt dev
, edit a file in the src/
folder and wait for the grunt task to finish recompiling the public/
folderIf 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.
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 customEUL-fswatch
name for easy cleanup and restart as needed. This will also help us not interfere with any otherfswatch
tasks that may be running once we get into a live server environment.
It worked, @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.
Moving this into Sprint 10.
@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.
This is no longer relevant as the templating engine is being decommissioned for Phase 2.
Determine what is being looked for (deletes, renames, moves), set up for multiple environments. Each domain should have its own index.