Non interactive use and CI

For developers and automation: running the installer without prompts, with parameters from the CLI and/or from a .env file. Same engine as the guided mode — there is only one flow.

How it kicks in

The installer is non-interactive when there is no TTY (in CI, for instance) or when you supply the parameters yourself. With no TTY the prompts are skipped and the CLI → .env → default cascade is used. Priority:

1. CLI argument   →   2. interactive prompt   →   3. .env file (--config)   →   4. default

Only a value passed on the CLI is never asked for at a prompt. A value in the .env is offered — as the prompt's suggested default — so on a TTY you see it and can change it, and what you answer wins. That is why the prompt sits above the file: a person at the terminal is deciding now, the file was written earlier.

With no TTY none of that happens: the prompts are skipped entirely and the cascade is CLI → .env → default, which is the case that matters for CI and for --config in a script.

With a .env file

sudo invok --config production.env

The .env is parsed declaratively (KEY=VALUE) and never executed as code, unlike the source of the old Bash version. A value like $(...) stays a literal string. Keys, types and defaults: .env file reference.

You write the .env. The repository ships no ready-made one, because it holds the admin and database passwords and configs/*.env is git-ignored by design. The two exceptions are the CI presets — configs/ci.env and configs/ci-nginx.env, throwaway files for ephemeral runners — which serve as a complete example to copy.

# production.env
ODOO_VERSION=18
ODOO_USER=odoo
ODOO_PORT=8069
DB_NAME=odoo
WITH_NGINX=true
# ODOO_ADMIN_PASSWD=...   # set a real password in production

With CLI flags (or a mix)

# everything on the CLI
sudo invok --version 18 --odoo-user odoo --db-name odoo --port 8069 --with-nginx

# .env as the base + a CLI override
sudo invok --config production.env --version 17

Every flag and default: CLI reference.

In CI and scripts

• Preview with no effects: --dry-run runs the snapshots only (read-only) and prints the plan. Ideal for validating a .env inside a pipeline.

  invok --config production.env --dry-run

  It works without root too, with a declared limit: some snapshots interrogate the system through sudo (PostgreSQL state, installed packages), and without privileges those questions get no answer. The steps involved show up as “snapshot unavailable” and the plan, though true, is incomplete. The installer says so before printing it. For the full plan: sudo … --dry-run.

• Passwords: do not pass the master password in the clear on shared machines; prefer a protected .env or a secret manager. The password never reaches the logs.

• Security note: non-interactively, admin_passwd=admin makes the installer stop — the weak password requires a confirmation that is impossible without a TTY. Set a different one.

• Logs: the run is traced to /var/log/invok.log, which is what you want for a post-mortem in CI. It exists from the very first installation and survives the rollback, deliberately: it is the account of what happened, and it matters most when something went wrong.

• Interruption: a SIGINT/SIGTERM makes the installation roll back; it does not kill it. From a script, signal the installer alone — sudo pkill -INT -x invok — because a pkill -f would also hit the sudo wrapping it, and two signals count as “second Ctrl-C”: immediate exit without rolling back.

Re-running the installer

What happens depends on how the previous run ended, and the installer decides on its own by reading the manifest:

Situation	What happens	Why
No installation registered	installs	the normal case
Installation interrupted (failed, Ctrl-C, power loss)	resumes where it stopped	steps already executed are not redone, and the record that those artifacts are ours is preserved — which is what keeps them removable later
Installation completed	stops (exit ≠ 0), naming the three ways on: --instance to add a second one beside it, rollback to remove it, --force to install over it	going ahead would overwrite the uninstall manifest with artifacts all marked “pre-existing”, and the instance would no longer be removable
Parameters differ from the registered ones	stops and says which field does not match	a manifest straddling two instances would make the rollback act on the wrong artifacts

In CI this means re-running is not idempotent by construction: if your script re-runs the installer expecting success, an already-installed instance gives it a non-zero exit. Use --force (which archives the previous manifest rather than deleting it), or rollback first — or, if what you actually want is a second installation, name it with --instance.

A .env for a named instance must name as little as possible. ODOO_USER, DB_USER, DB_NAME and ODOO_INSTALL_DIR are derived from the instance, and an explicit value beats a derived one: a file that spells them out gives the second instance the first one's user, role and database, silently. Name the instance and the port, and let the rest follow. See More than one instance.

Pre-existing resources are left untouched in every case — a DB or a user that was already there is never removed (see The rollback model).

---

See also: Development and contributing (build, tests, architecture).