VCS Integration & UI — How it would work
Problem & goals
- Automate plans in pull requests and applies after merge, with clear visibility.
- Provide a minimal UI to manage repo connections and observe runs.
User journeys
- Connect a repo/org via a VCS App install (e.g., GitHub App).
- Map repo paths → unit IDs; configure plan/apply triggers.
- PR open/update → plan preview comment; merge → apply; view run history in UI.
High-level design
- Webhooks: handle PR events; dedupe and schedule runs against units.
- Config: per-repo mapping file (units, paths, variables) or UI forms.
- UI: minimal pages for connection status, run lists, and simple troubleshooting.
- RBAC: reuse OpenTaco roles for visibility and control; per-repo scoping.
Shapes (provisional)
- Entity: Repo connection; mappings; webhook delivery logs; run records.
- APIs: CRUD for connections/mappings; webhook receiver; run listing by repo/path.
- Comments: provider-specific adapters (start with GitHub).
Open questions
- Multi-VCS support sequence; auth flows per provider.
- Mapping strategies (monorepo subpaths, multi-root workspaces).
- UI tech and hosting model (embedded vs separate).