GitOps¶
Ampora can ingest configurations from a registered Git repository. Every commit on the tracked branch that changes a tracked file becomes a new draft Configuration version.
| Page | Use it for |
|---|---|
| Registering a Git source | Add a repo, set credentials, choose a path glob |
| Webhooks | (Tranche 2) Lower-latency sync via inbound HTTPS hooks |
The tutorial that walks the whole flow end-to-end: Tutorials → GitOps-driven configuration.
Why use GitOps¶
- Source of truth in your repo. Your existing review process applies (PRs, branch protection, CODEOWNERS).
- Identical staging and prod. A successful PR in
mainis the same content rolled to both. - Audit by commit hash. Every imported version carries the upstream commit SHA.
- Disaster recovery. Even a complete Ampora wipe leaves the configuration history intact in Git.
What the integration covers (Tranche 1)¶
- Read-only sync.
- Polling — no webhooks required.
- Per-source path glob filter.
- Per-source credentials (PAT or SSH key), wrapped at rest, no read-back.
- Per-source poll interval (15 s – 1 h).
- Sync run history (30 days).
What is on the roadmap¶
- Webhooks for sub-second sync (ADR-049, Tranche 2).
- UI-edits-as-PR — click "Edit" on a Git-controlled config and submit a PR back to the repo. Tranche 2.
- Pre-merge validation — Ampora exposes a webhook the Git host can call to validate a PR before merge.
For now, Git-controlled configurations are read-only in the editor; edits round-trip via your usual Git workflow.