mix aurora_meter.install (Aurora Meter v1.0.0)

Installs Aurora Meter into a Phoenix (or plain Ecto) application in one step, powered by Igniter:

mix igniter.install aurora_meter
# or, once the dep is in mix.exs:
mix aurora_meter.install --repo MyApp.Repo

It will

• add config :aurora_meter, repo: ..., pubsub: ..., plans: ... to config/config.exs
• add AuroraMeter to your application's children, after the repo and PubSub
• create a MyApp.Plans module with a :free and a :pro plan (never overwrites one you have)
• generate the migration that delegates to AuroraMeter.Migration

Options: --repo, --pubsub, --plans (module names; all inferred when omitted), --feature-policy, --events-source, --oban and --check-support.

--feature-policy

mix aurora_meter.install --repo MyApp.Repo --feature-policy warn

Writes undeclared_feature_policy, one of deny (the default for a new install), raise, warn or allow. It is written into your own config/config.exs rather than left to the library default, so that a later release changing that default cannot change what your application does.

It is created and never changed. A second run of this task on a host that already sets the key keeps the host's value, says so, and names what a fresh install would have been given. That is deliberate: the upgrade path for an existing install is :warn, then mix aurora_meter.features until it reports nothing, then :deny, and an installer run for an unrelated reason must not put a running application back to the start of it.

--events-source

mix aurora_meter.install --repo MyApp.Repo \
  --events-source tokens:events --events-source requests:buffered

Writes feature_sources. A feature listed as events is recorded durably through AuroraMeter.record/4 and projected, and AuroraMeter.track/4 raises for it: a feature has exactly one reporting source. Pass the switch once per feature. Like the policy above it is created and never changed.

An unknown source, a name that is not a feature name, or the same feature twice stops the task before it writes anything at all.

--oban

mix aurora_meter.install --repo MyApp.Repo --oban

Wires the optional AuroraMeter.Oban.* workers into the host's own Oban instance. It needs Oban to be a dependency of your application: without one the switch refuses, names the line to add to mix.exs, and writes nothing.

With one:

• config :my_app, Oban when it is absent, with the repo, an aurora_meter queue and a Oban.Plugins.Cron plugin carrying AuroraMeter.Oban.cron_entries/1;
• when it is present, the aurora_meter queue only if absent, the Cron plugin only if absent, and each recommended crontab entry only if no entry already names that worker;
• the AuroraMeter.Oban.validate!/1 call in Application.start/2.

It never edits a value you already set. A queue concurrency you chose, a schedule you chose, and the order of your plugins all survive untouched; an entry whose worker is already scheduled is left exactly as written, whatever its schedule. That is the rule, and it is why running the installer twice changes nothing at all.

--check-support

mix aurora_meter.install --check-support

Prints what this host resolves against Aurora Meter's declared floors and exits non-zero when something present is below one. It writes no file, generates nothing, and connects to no database: a Postgres server version can only be learned by asking the server, so the floor is printed and the check is yours to run. See AuroraMeter.Install.Support.

--dry-run

--dry-run is Igniter's own global switch and needs no declaration here: it prints the diff the task would apply and writes nothing. It works for this task exactly as it works for every other Igniter task, including the --oban work above, and it prints that diff in a script as well as at a terminal. See --dry-run under "Exit status and scripts" below.

Exit status and scripts

A refusal (a bad --feature-policy, a bad --events-source, --oban without Oban) writes nothing and exits 1, so set -e and if ! mix ... do what you expect. Igniter's own behaviour is to display the issues and exit 0; this task and Aurora Meter Pro's wrap run/1 to add the status (open-findings.md X366).

--dry-run prints its change set whether or not you are at a terminal. Igniter treats a run whose standard input is not a character device as --yes, and --yes suppresses the diff, so the plain mix aurora_meter.install --dry-run in a CI step printed nothing at all: it wrote no file, which is right, and reported no change set, which is the only reason to run it (X376). A dry run writes nothing and is never asked to confirm, so an implicit --yes has nothing to agree to here and this task drops it. Pass --yes explicitly and you get the quiet form you asked for.

Without Igniter available the task falls back to generating the migration and printing the remaining steps; --check-support works there too.