To allow the non-SaaS version of Fizzy to default to single-tenant mode,
we'll enable a `multi_tenant.enabled` config option here that overrides
the default behaviour.
* Sentry: use KAMAL_VERSION for release tracking
Kamal injects KAMAL_VERSION at container runtime with the git SHA,
so no need to bake it into the Docker image via build args.
* Sentry: serve as Rails error reporter
Sentry receives errors from Rails.error.report and Active Job
`retry_on/discard_on report: true`.
Error context is provided by Rails.error.set_context in Fizzy's
Authentication concern and ApplicationJob.
To keep as much of this as we can in the `fizzy-saas` gem, this PR
opts to store console/audits models in a separate database, and so:
- the gem contains the migrations and the database config
- the app contains a separate schema file distinctly for SaaS concerns
- Rails' current behavior prevents us from easily keeping this file in the gem
Also note that the stock `audits1984` schema is updated to reference
the auditor via a UUID foreign key.
Finally, in order for the database schema file to be located in the
gem directory (and not the application directory), it's necessary to
monkeypatch `AR::DatabaseTasks.schema_dump_path` to support absolute
paths. This functionality has been proposed upstream in
https://github.com/rails/rails/pull/56290 but is awaiting a decision
from the core team.
ref: https://app.fizzy.do/5986089/cards/2469
ref: #17
per autotuner advice:
The following suggestions reduce the number of minor garbage
collection cycles, specifically a cycle called "malloc". Your app
runs malloc cycles in approximately 25.00% of all minor garbage
collection cycles.
I think this was hallucinated in the original commit. This is causing
racing between beta and prod, and as a result beta was attempting to
send emails for production.
Fortunately, smtp is not configured in beta and prevented bad emails
from going out. 😅
Matthew Kent