1.9 Step | CloneOdooRepo

Clones the Odoo sources into <install_dir>/odoo, reversibly. It lives in src/steps/clone_odoo_repo.rs. The first of the three sub-steps the Bash monolith install_odoo is broken into (clone → venv → pip). Every operation runs as the odoo user (least privilege), not as root.

---

Splitting a monolithic step

In Bash, install_odoo is one block. Here it becomes three steps with distinct undos:

Sub-step	Undo
1.9 CloneOdooRepo	rm -rf of the sources (+ the container if empty)
1.10 CreateVirtualenv	rm -rf sandbox
1.11 InstallPythonRequirements	none (absorbed by 1.10)

Decomposing a monolith into sub-steps with clear undo boundaries — and discovering that one has no undo of its own precisely because another covers it — is a pattern that recurs (nginx, control script).

---

Life cycle

Phase	Behaviour
snapshot	detects the state of the sources (detect_odoo_source): absent / git on the right branch / tarball (odoo-bin without .git) / invalid directory
run	creates the directory structure as odoo, then clones (with retries and a fallback). Preexisting → skip. dry_run → log
undo	CreatedByUs only: rm -rf of the repo and repos/, plus removal of the install_dir container if empty

Snapshot: four states

• git on the expected branch → Preexisting (git-existing), skip.
• tarball (odoo-bin, no .git) → Preexisting (tarball-existing), skip.
• a different branch → error: it may hold work in progress. It is not silently regenerated (“remove it by hand … if you want to re-clone”).
• invalid directory (neither .git nor odoo-bin, under our install_dir) → warning + regeneration.
• absent → CreatedByUs after the run.

---

Download robustness: retries + fallback

git clone (N retries, attempt*2s backoff, artifacts cleaned between attempts)
   └─ failed after N attempts → tarball fallback (codeload.github.com)
        └─ the tarball failed too → error

Git arguments faithful to Bash: -c http.version=HTTP/1.1 -c core.compression=0 clone … --branch <ver> --single-branch --no-tags --depth <N>. Default depth 5 (GIT_DEPTH), default retries 3 (GIT_CLONE_RETRIES). The source mode (git or tarball) is recorded in the snapshot for the post-mortem.

Both the clone and the tarball are network operations, so they carry a timeout (ODOO_NETWORK_TIMEOUT_SECS, 300s by default, 0 disables it) enforced inside the SystemOps boundary. A timeout consumes one attempt. Local long operations do not get one: cutting them short would do more damage than waiting.

---

Perimeter: install_dir yes, /opt/odoo no

This step lives inside <install_dir> (/opt/odoo/odoo18, say), one level below /opt/odoo. Here rm -rf is legitimate: it is our sources directory, created entirely by us. /opt/odoo remains 1.1 PrepareOptRoot's business.

The container install_dir is removed only if empty, after the venv and config undos have run first (reverse order) — the same pattern as /opt/odoo. If it holds anything else (including pre-existing material), it is left intact.

---

Design notes

• git_clone is a single attempt inside the SystemOps boundary; the retry, backoff and fallback are orchestrated by the step (testable with a mock that fails N times).
• Best-effort undo on every removal.
• Tests: absent (clone + undo rm -rf), git-existing (no-op), branch mismatch (error), retries (3 attempts + 2 cleanups), tarball fallback (fires; if it fails too → error).