276 lines
5.7 KiB
Markdown
276 lines
5.7 KiB
Markdown
# 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`
|