edu/stem-launcher
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add token list command

Browse Source
This commit is contained in:
mpabi
2026-04-26 22:28:31 +02:00
parent bd2d530852
commit 8c6f713de5
4 changed files with 300 additions and 53 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/tokens.md
+113 -47
View File
@@ -1,31 +1,41 @@
# Tokens
Plik opisuje model pracy z tokenami w launcherze.
Ten dokument opisuje model tokenow uzywany przez `rvctl`.
## Zrodlo prawdy
## Zasada
Sa dwa miejsca, w ktorych moga byc zapisane dane dostepowe:
`tokens.json` synchronizujemy z repo `rv-launcher`. Remoty kart pracy i repo
odpowiedzi sa generowane jako pochodne konfiguracji launchera, a nie jako osobne
zrodla prawdy dla tokenow.
- remote URL w repo, na przyklad `http://u1:SECRET@host/org/repo.git`
W praktyce oznacza to:
- `r1` w repo `rv-launcher` jest miejscem startowym do pobrania tokena z remote
- `tokens.json` jest lokalnym store sekretow i metadanych tokenow
- karty pracy dostaja remote na podstawie ustawien launchera i komend typu `submission`
- `tokens scan` jest read-only i niczego nie zapisuje
## Zrodlo Prawdy
Sa dwa miejsca, ktore `rvctl` potrafi porownac:
- git remote w repo `rv-launcher`, np. `http://u1:SECRET@host/org/repo.git`
- lokalny plik `~/dev/workspace/rv/tokens/tokens.json`
`tokens scan` tylko porownuje oba miejsca i niczego nie zapisuje.
`tokens sync remote r1` czyta remote `r1` i zapisuje jego dane w
`tokens.json`.
`tokens sync store r1` zapisuje rekord `r1` z `tokens.json` do git remote
`r1`.
`tokens update r1` nie synchronizuje sekretu; tylko pobiera z API metadane
tokenu: `valid`, `scope`, `org_perm` i `repo_perm`.
Kierunek jest jawny:
W podstawowym flow `tokens.json` synchronizujemy z repo `rv-launcher`. Remoty
kart pracy i repo odpowiedzi sa generowane jako pochodne konfiguracji launchera,
nie jako osobne zrodla prawdy dla tokenow.
- `tokens list store` pokazuje tylko rekordy w `tokens.json`
- `tokens list remote` pokazuje tylko git remotes
- `tokens sync remote r1` czyta git remote `r1` i zapisuje rekord do `tokens.json`
- `tokens sync store r1` czyta `tokens.json` i zapisuje auth do git remote `r1`
- `tokens update r1` nie synchronizuje sekretu, tylko pobiera metadane z API
- `tokens remove ... r1` usuwa rekord ze store, git remote albo oba miejsca
## Format `tokens.json`
Aktualny format to `version: 3`. Glownym rekordem jest remote-token. Pole
`id` jest obowiazkowe i musi byc takie samo jak nazwa git remote, np. `r1`
albo `r1a`.
Aktualny format to `version: 3`. Glownym rekordem jest jeden remote-token.
Pole `id` jest obowiazkowe i musi byc takie samo jak nazwa git remote, np.
`r1` albo `r1a`.
```json
{
@@ -74,30 +84,30 @@ albo `r1a`.
}
```
Schemat JSON jest w pliku `doc/tokens.schema.json`.
Pelny schemat jest w `doc/tokens.schema.json`.
## Pola
Pola synchronizowane z remote URL-a:
Pola synchronizowane z git remote:
- `id` - nazwa git remote, np. `r1`; to jest klucz rekordu w `tokens.json`
- `server.endpoint` - endpoint serwera, na przyklad `http://77.90.8.171:3001`
- `server.type` - typ serwera, na przyklad `gitea`, `github`, `gitlab`, `unknown`
- `id` - nazwa git remote, np. `r1`; to jest klucz rekordu
- `server.endpoint` - endpoint serwera, np. `http://77.90.8.171:3001`
- `server.type` - typ serwera, np. `gitea`, `github`, `gitlab`, `unknown`
- `user` - login z URL-a, czyli lewa strona `http://u1:SECRET@...`
- `value` - sekret tokena
- `org` - organizacja z URL-a
- `repo` - repo z URL-a
Pola wzbogacane przez API przy `tokens update r1`:
Pola pobierane z API przez `tokens update r1`:
- `valid` - `forever`, data `expires_at`, `invalid`, `?` albo `!`
- `valid` - `forever`, data wygasniecia, `invalid`, `?` albo `!`
- `scope` - mapa scope tokena
- `org_perm` - mapa praw w organizacji
- `repo_perm` - mapa praw w repo
- `org_perm` - mapa praw uzytkownika w organizacji
- `repo_perm` - mapa praw uzytkownika w repo
## Porownanie
Porownanie z `git remote -v` jest robione po:
`tokens scan` porownuje git remote i `tokens.json` po:
```text
server.endpoint + id + user + value + org + repo
@@ -106,17 +116,17 @@ server.endpoint + id + user + value + org + repo
Znacznik w kolumnie `token_ref`:
- `*` - remote i `tokens.json` sa zgodne
- `R` - wpis istnieje tylko w remote URL-u
- `R` - wpis istnieje tylko w git remote
- `S` - wpis istnieje tylko w `tokens.json`
- `!` - remote i `tokens.json` sa zgodne, ale zapisany token jest `invalid` albo ma blad walidacji
- `!` - wpis jest sparowany, ale token jest `invalid` albo ma blad sprawdzania
Bez zgodnego wpisu kolumny `valid`, `scope`, `org` i `repo` w raporcie maja
wartosc `?`, bo launcher nie pokazuje metadanych API dla niesparowanych wpisow.
Dla niesparowanych wpisow `rvctl` pokazuje `?` w kolumnach `valid`, `scope`,
`org` i `repo`, bo metadane API sa wiarygodne dopiero dla rekordu ze store.
## Uprawnienia
W `tokens.json` uprawnienia sa zapisane jako mapy klucz-wartosc. W tabeli CLI sa
pokazywane skrocone maski.
pokazywane jako zwarte maski.
Naglowki masek:
@@ -136,7 +146,7 @@ Kategorie `scope`:
- `r` - repository
- `u` - user
Znaki w `scope`:
Wartosci w `scope`:
- `w` - read/write
- `r` - read
@@ -159,25 +169,80 @@ Kategorie `repo_perm`:
- `w` - write
- `r` - read
Znaki w `org_perm` i `repo_perm`:
Wartosci w `org_perm` i `repo_perm`:
- `+` - flaga wlaczona
- `-` - flaga wylaczona
- `?` - nie wczytano
- `!` - blad wczytania
## Typowy Flow
W repo `rv-launcher`:
```bash
git remote add r1 http://u1:TOKEN@77.90.8.171:3001/edu-tools/rv-launcher.git
./rvctl tokens scan
./rvctl tokens sync remote r1
./rvctl tokens update r1
./rvctl tokens scan
```
Po `sync remote` sekret jest w `tokens.json`. Po `update` `rvctl` dopisuje
`valid`, `scope`, `org_perm` i `repo_perm`.
Jesli chcesz tylko zobaczyc jedno zrodlo, bez porownywania:
```bash
./rvctl tokens list remote
./rvctl tokens list store
./rvctl tokens list both
```
Jesli remote ma byc bez sekretu, a token ma zostac tylko w `tokens.json`:
```bash
./rvctl tokens remove remote r1
git remote add r1 http://77.90.8.171:3001/edu-tools/rv-launcher.git
```
Jesli trzeba ponownie wpisac sekret ze store do remota:
```bash
./rvctl tokens sync store r1
```
## Komendy
### `tokens scan`
Read-only. Czyta remote URL-e i `tokens.json`, a potem wypisuje tabele
`tokens`. Nie tworzy i nie modyfikuje `tokens.json`.
Read-only. Czyta git remote i `tokens.json`, laczy wpisy w pary i wypisuje
tabele `tokens`. Nie tworzy i nie modyfikuje `tokens.json`. Bez `--repo`
czyta repo zawierajace `rvctl`.
```bash
./rvctl tokens scan
./rvctl tokens scan --repo ~/dev/workspace/rv/series/inf/03
./rvctl tokens scan --repo ~/dev/workspace/rv/tools/rv-launcher
```
### `tokens list store|remote|both`
Read-only. Wypisuje jedno zrodlo bez porownywania go z drugim. To odroznia
`list` od `scan`: `list` odpowiada na pytanie "co jest zapisane tutaj", a
`scan` odpowiada na pytanie "czy store i remote sa zgodne".
```bash
./rvctl tokens list store
./rvctl tokens list remote
./rvctl tokens list both
./rvctl tokens list remote --repo ~/dev/workspace/rv/tools/rv-launcher
```
Przelaczniki:
- `--repo PATH` - repo, z ktorego listowane sa git remotes; bez tej opcji uzywane jest repo zawierajace `rvctl`
- `--server ENDPOINT` - ogranicza wynik do jednego endpointu
### `tokens sync remote REMOTE_ID`
Kopiuje dane dostepowe z git remote do `tokens.json`. Nie pobiera metadanych z
@@ -190,7 +255,7 @@ API. Bez `--repo` czyta repo zawierajace `rvctl`.
### `tokens update REMOTE_ID`
Pobiera z API metadane dla rekordu `REMOTE_ID` juz zapisanego w `tokens.json`.
Pobiera z API metadane dla rekordu `REMOTE_ID` zapisanego w `tokens.json`.
Nie zmienia git remote URL-a i nie kopiuje sekretu z remote.
```bash
@@ -204,21 +269,19 @@ Zapisuje dane z rekordu `REMOTE_ID` w `tokens.json` do git remote o tej samej
nazwie. Bez `--repo` zapisuje do repo zawierajacego `rvctl`.
```bash
./rvctl tokens sync store r1 --repo ~/dev/workspace/rv/series/inf/03
./rvctl tokens sync store r1 --repo PATH --replace
./rvctl tokens sync store r1
./rvctl tokens sync store r1 --replace
```
### `tokens remove store|remote|both REMOTE_ID`
Usuwa rekord `REMOTE_ID` z `tokens.json`, git remote albo oba miejsca.
Domyslnym repo dla `remote` i `both` jest repo, w ktorym lezy `rvctl`. Inne
repo mozna wskazac przez `--repo PATH`.
Usuwa rekord ze store, git remote albo oba miejsca. Bez `--repo` operacje
`remote` i `both` dzialaja na repo zawierajacym `rvctl`.
```bash
./rvctl tokens remove store r1
./rvctl tokens remove remote r1
./rvctl tokens remove both r1
./rvctl tokens remove remote r1 --repo ~/dev/workspace/rv/series/inf/03
```
Przelaczniki:
@@ -252,15 +315,18 @@ nazwie git remote.
### `tokens stats`
Pokazuje kontekst, tabele `tokens` i podsumowanie statusow endpointow.
Pokazuje kontekst, tabele `tokens` i podsumowanie statusow endpointow. Bez
`--repo` czyta repo zawierajace `rvctl`.
```bash
./rvctl tokens stats --repo ~/dev/workspace/rv/series/inf/03
./rvctl tokens stats
./rvctl tokens stats --repo ~/dev/workspace/rv/tools/rv-launcher
```
### Komendy zgodnosci
Stare komendy nadal dzialaja, ale sa mniej jednoznaczne:
Stare komendy nadal dzialaja, ale w nowych instrukcjach preferujemy jawne
`sync remote`, `sync store` i `update REMOTE_ID`.
```bash
./rvctl tokens update --from remotes --repo PATH