docs(snapshot): sync workspace documentation
This commit is contained in:
275
gitea-repo-cleanup-plan.md
Normal file
275
gitea-repo-cleanup-plan.md
Normal file
@@ -0,0 +1,275 @@
|
||||
# Gitea repo cleanup plan
|
||||
|
||||
Stan na `2026-03-13`.
|
||||
|
||||
Cel:
|
||||
- uporzadkowac repo `trade/*` na `gitea.mpabi.pl`
|
||||
- wskazac jednoznaczne source of truth
|
||||
- odseparowac repo aktywne od historycznych lub porzuconych
|
||||
- uniknac kasowania aktywnych danych w ciemno
|
||||
|
||||
## Zasady
|
||||
|
||||
1. Najpierw archiwizacja, nie usuwanie.
|
||||
2. Najpierw ustalic source of truth, potem porzadkowac branche.
|
||||
3. Nie zostawiac repo, ktore duplikuja aktywny kod w innym miejscu.
|
||||
4. `trade-deploy` i `trade-iac` traktowac jako repo operacyjne o wysokim priorytecie.
|
||||
5. Po cleanupie kazde aktywne repo ma miec:
|
||||
- poprawny remote
|
||||
- aktywnego ownera
|
||||
- jasna role
|
||||
- aktualne README
|
||||
|
||||
## Repo po repo
|
||||
|
||||
### `trade-frontend`
|
||||
|
||||
Status:
|
||||
- aktywne
|
||||
- lokalne source of truth dla UI i `apps/visualizer`
|
||||
- na Gitei sa juz aktualne branche robocze
|
||||
|
||||
Decyzja:
|
||||
- zostawic
|
||||
|
||||
Dzialania:
|
||||
- utrzymac jako repo dla:
|
||||
- frontend SPA
|
||||
- visualizer
|
||||
- dokumentacji frontend/runtime, jesli ma zostac blisko kodu
|
||||
- zamknac stare branche po merge
|
||||
- nie wydzielac ponownie `trade-visualizer`
|
||||
|
||||
### `trade-api`
|
||||
|
||||
Status:
|
||||
- aktywne logicznie
|
||||
- lokalny checkout nadal wskazuje na stare `rv32i.pl`
|
||||
- lokalny `main` rozjechany z `gitea.mpabi.pl/trade/trade-api`
|
||||
|
||||
Decyzja:
|
||||
- zostawic
|
||||
- uporzadkowac natychmiast
|
||||
|
||||
Dzialania:
|
||||
- przepiac local remote na `gitea.mpabi.pl`
|
||||
- porownac lokalny `main` z Gitea `main`
|
||||
- zdecydowac:
|
||||
- czy lokalny checkout jest historyczny i do porzucenia
|
||||
- czy trzeba go zrebase'owac/cherry-pickowac na nowe repo
|
||||
- dopiero potem wznowic aktywne prace
|
||||
|
||||
### `trade-ingestor`
|
||||
|
||||
Status:
|
||||
- aktywne
|
||||
- lokalny checkout jest zgodny z Gitea
|
||||
- rola w runtime wymaga przedefiniowania
|
||||
|
||||
Decyzja:
|
||||
- zostawic
|
||||
|
||||
Dzialania:
|
||||
- zachowac repo
|
||||
- zmienic role z glownego ingestu na:
|
||||
- pomocniczy ingest
|
||||
- backfill
|
||||
- normalizacja danych pomocniczych
|
||||
- dopisac README z aktualna rola po redesignie DLOB
|
||||
|
||||
### `trade-drift-dlob`
|
||||
|
||||
Status:
|
||||
- repo istnieje na Gitei
|
||||
- lokalnie aktywnie pracujesz na `dlob-server`
|
||||
- source of truth nie jest jeszcze czyste
|
||||
|
||||
Decyzja:
|
||||
- zostawic
|
||||
- uporzadkowac zaraz po `trade-api`
|
||||
|
||||
Dzialania:
|
||||
- zdecydowac, czy `dlob-server` ma zostac przeniesiony do `trade-drift-dlob`
|
||||
- jesli tak:
|
||||
- uznac `trade-drift-dlob` za docelowe repo
|
||||
- przeniesc aktualny kod i workflow tam
|
||||
- jesli nie:
|
||||
- zarchiwizowac `trade-drift-dlob`
|
||||
- ale tylko po migracji kodu do repo docelowego
|
||||
|
||||
### `trade-deploy`
|
||||
|
||||
Status:
|
||||
- aktywne
|
||||
- repo GitOps
|
||||
- na Gitei jest aktualny branch z overlay `mevnode-bot`
|
||||
|
||||
Decyzja:
|
||||
- zostawic
|
||||
|
||||
Dzialania:
|
||||
- utrzymac jako jedyne source of truth dla runtime `k3s`
|
||||
- nie trzymac runtime patchy poza tym repo
|
||||
- porzadkowac branche po merge
|
||||
|
||||
### `trade-iac`
|
||||
|
||||
Status:
|
||||
- aktywne
|
||||
- zawiera bootstrap/infra
|
||||
- branch roboczy `step2-solana-rpc` jest na Gitei
|
||||
|
||||
Decyzja:
|
||||
- zostawic
|
||||
|
||||
Dzialania:
|
||||
- utrzymac jako source of truth dla:
|
||||
- bootstrap hostow
|
||||
- k3s
|
||||
- wireguard
|
||||
- provisioning
|
||||
- po merge wyczyscic stare branche robocze
|
||||
|
||||
### `trade-infra`
|
||||
|
||||
Status:
|
||||
- repo istnieje
|
||||
- lokalny checkout jest zsynchronizowany
|
||||
- jego rola nie jest dzis jednoznaczna
|
||||
|
||||
Decyzja:
|
||||
- tymczasowo zostawic
|
||||
- wymagac decyzji architektonicznej
|
||||
|
||||
Dzialania:
|
||||
- wybrac jedna z dwoch rol:
|
||||
- umbrella/superproject
|
||||
- repo narzedziowe ops
|
||||
- jesli nie dostanie konkretnej roli, zarchiwizowac
|
||||
|
||||
### `trade-doc`
|
||||
|
||||
Status:
|
||||
- repo istnieje
|
||||
- lokalny checkout zsynchronizowany
|
||||
- czesc aktywnej dokumentacji zyje jednak w `trade-frontend`
|
||||
|
||||
Decyzja:
|
||||
- tymczasowo zostawic
|
||||
- wymagac decyzji o modelu dokumentacji
|
||||
|
||||
Dzialania:
|
||||
- wybrac jedna z dwoch strategii:
|
||||
- docs centralne w `trade-doc`
|
||||
- docs przy repo kodowym
|
||||
- jesli wybierzesz docs przy kodzie:
|
||||
- `trade-doc` zarchiwizowac po migracji najwazniejszych materialow
|
||||
|
||||
### `trade-visualizer`
|
||||
|
||||
Status:
|
||||
- repo istnieje na Gitei
|
||||
- lokalnie `visualizer` zyje w `trade-frontend`
|
||||
- brak sensu utrzymywac dwoch rownoleglych repo dla tego samego obszaru
|
||||
|
||||
Decyzja:
|
||||
- archiwizowac
|
||||
|
||||
Dzialania:
|
||||
- sprawdzic, czy nie ma tam unikalnego kodu do uratowania
|
||||
- jesli nie ma:
|
||||
- oznaczyc repo jako archived
|
||||
- dopisac w opisie, ze `visualizer` jest teraz w `trade-frontend`
|
||||
|
||||
### `trade-inc`
|
||||
|
||||
Status:
|
||||
- repo istnieje na Gitei
|
||||
- brak lokalnego checkoutu
|
||||
- brak widocznego uzycia w deployu i codziennej pracy
|
||||
|
||||
Decyzja:
|
||||
- archiwizowac
|
||||
|
||||
Dzialania:
|
||||
- sprawdzic, czy nie ma tam czegos krytycznego historycznie
|
||||
- jesli nie ma:
|
||||
- oznaczyc repo jako archived
|
||||
|
||||
## Priorytety wykonania
|
||||
|
||||
### Faza 1. Uporzadkowanie aktywnych repo
|
||||
|
||||
1. `trade-api`
|
||||
2. `trade-drift-dlob`
|
||||
3. `trade-deploy`
|
||||
4. `trade-iac`
|
||||
|
||||
Cel:
|
||||
- miec wszystkie aktywne repo na poprawnych remote
|
||||
- miec jasny source of truth dla kodu i deployu
|
||||
|
||||
### Faza 2. Decyzje architektoniczne
|
||||
|
||||
1. `trade-doc`
|
||||
2. `trade-infra`
|
||||
|
||||
Cel:
|
||||
- zdecydowac, czy te repo maja nadal odrebna wartosc
|
||||
|
||||
### Faza 3. Archiwizacja repo zbednych
|
||||
|
||||
1. `trade-visualizer`
|
||||
2. `trade-inc`
|
||||
|
||||
Cel:
|
||||
- odchudzic Gitee bez utraty historii
|
||||
|
||||
## Plan zmian operacyjnych
|
||||
|
||||
### Krok 1. `trade-api`
|
||||
|
||||
- przepiac local remote na `gitea.mpabi.pl`
|
||||
- pobrac `origin/main`
|
||||
- porownac commit lokalny z Gitea
|
||||
- zdecydowac, czy:
|
||||
- zachowac lokalny checkout
|
||||
- czy porzucic go i klonowac od nowa
|
||||
|
||||
### Krok 2. `trade-drift-dlob`
|
||||
|
||||
- porownac repo `trade-drift-dlob` z lokalnym `dlob-server`
|
||||
- wybrac repo docelowe
|
||||
- dopiero potem przenosic redesign DLOB
|
||||
|
||||
### Krok 3. `trade-doc` vs docs przy kodzie
|
||||
|
||||
- jesli dokumentacja ma byc centralna:
|
||||
- przenosic nowe materialy do `trade-doc`
|
||||
- jesli dokumentacja ma byc przy repo:
|
||||
- stopniowo wygaszac `trade-doc`
|
||||
|
||||
### Krok 4. Archiwizacja
|
||||
|
||||
- ustawic `Archived` na:
|
||||
- `trade-visualizer`
|
||||
- `trade-inc`
|
||||
- bez usuwania repo
|
||||
|
||||
## Rekomendacja koncowa
|
||||
|
||||
Docelowy zestaw aktywnych repo:
|
||||
- `trade-frontend`
|
||||
- `trade-api`
|
||||
- `trade-ingestor`
|
||||
- `trade-drift-dlob`
|
||||
- `trade-deploy`
|
||||
- `trade-iac`
|
||||
|
||||
Repo warunkowe:
|
||||
- `trade-infra`
|
||||
- `trade-doc`
|
||||
|
||||
Repo do archiwizacji:
|
||||
- `trade-visualizer`
|
||||
- `trade-inc`
|
||||
Reference in New Issue
Block a user