Donal McBreen
e8abc66eba
Add a single search_index table for full-text search of cards and comments. For the search there is a full-text index on the title and content columns. The board_ids is also included in the table and accessible board ids are pre-loaded and included in the search query. This allows us to filter out inaccessible records before joining with other tables. Right now the search is just using boolean search. This would give us a bunch of syntax options (see https://dev.mysql.com/doc/refman/8.4/en/fulltext-boolean.html) except the search query filters those out. I've removed the searchable_by method for now - everything is built on the assumption that there's a single search index table and all data must fit into it. Queries are written in SQL, we don't have a SearchIndex ActiveRecord model. That's because we'll likely want to shard the table and it will be simpler to just keep with the raw SQL for that. There's no stemming, highlighting or snippet extraction yet - we are dumping the full description in the search results. Data can be reindexed with the search:reindex rake task.
Fizzy
Setting up for development
First get everything installed and configured with:
bin/setup
If you'd like to load fixtures:
bin/rails db:fixtures:load
And then run the development server:
bin/dev
You'll be able to access the app in development at http://development-tenant.fizzy.localhost:3006
Running tests
For fast feedback loops, unit tests can be run with:
bin/rails test
The full continuous integration tests can be run with:
bin/ci
Tests
Outbound Emails
Development
You can view email previews at http://fizzy.localhost:3006/rails/mailers.
You can enable or disable letter_opener to
open sent emails automatically with:
bin/rails dev:email
Under the hood, this will create or remove tmp/email-dev.txt.
Environments
Fizzy is deployed with Kamal. You'll need to have the 1Password CLI set up in order to access the secrets that are used when deploying. Provided you have that, it should be as simple as bin/kamal deploy to the correct environment.
Beta
Beta is primarily intended for testing product features.
Beta tenant is:
This environment uses local disk for Active Storage.
Staging
Staging is primarily intended for testing infrastructure changes.
This environment uses a FlashBlade bucket for blob storage, and shares nothing with Production. We may periodically copy data here from production.
Production
This environment uses a FlashBlade bucket for blob storage.