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

Use Polish diacritics in docs

Browse Source
This commit is contained in:
mpabi
2026-04-29 02:09:30 +02:00
parent dedde573f7
commit b67c5b5204
6 changed files with 326 additions and 321 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/tokens.md
+69 -66
View File
@@ -1,18 +1,18 @@
# Tokens
`rvctl` obsluguje tokeny Gitea w dwoch miejscach:
`rvctl` obsługuje tokeny Gitea w dwóch miejscach:
- `tokens.json` - lokalny store sekretow i metadanych tokenow
- `tokens.json` - lokalny store sekretów i metadanych tokenów
- `.git/config` - git remotes w konkretnym repo
Rekord w `tokens.json` zawiera token, endpoint serwera, login oraz docelowe
`org/repo`. Git remote sluzy tylko do operacji Git (`fetch`, `push`) albo do
`org/repo`. Git remote służy tylko do operacji Git (`fetch`, `push`) albo do
pierwszego wczytania tokena do store.
Bez `--repo` komendy tokenow dzialaja na repo `rv-launcher`. Dla kart pracy albo
Bez `--repo` komendy tokenów działają na repo `rv-launcher`. Dla kart pracy albo
innych repo podaj `--repo PATH`.
## Szybki Flow
## Szybki przepływ
Startujemy od git remota z tokenem w URL-u:
@@ -40,15 +40,15 @@ Pobieramy z API metadane tokena:
./rvctl tokens update r1
```
Sprawdzamy zgodnosc remote i store:
Sprawdzamy zgodność remote i store:
```bash
./rvctl tokens cmp
```
Po poprawnej synchronizacji `compare`/`cmp` powinien pokazac `*` przy `r1`.
Po poprawnej synchronizacji `compare`/`cmp` powinien pokazać `*` przy `r1`.
Jesli chcesz sprawdzic, czy store da sie odtworzyc z remota, usun tylko rekord
Jeśli chcesz sprawdzić, czy store da się odtworzyć z remota, usuń tylko rekord
ze store i wczytaj go ponownie z git remota:
```bash
@@ -58,27 +58,30 @@ ze store i wczytaj go ponownie z git remota:
./rvctl tokens cmp
```
Po `sync remote` metadane API sa ustawiane na `?`, dlatego `update` jest zawsze
Po `sync remote` metadane API są ustawiane na `?`, dlatego `update` jest zawsze
kolejnym krokiem.
## Dwa Zrodla
## Dwa Źródła
`rvctl` rozroznia dwa miejsca:
`rvctl` rozróżnia dwa miejsca:
- git remote w repo, np. `http://u1:SECRET@host/org/repo.git`
- lokalny store `~/dev/workspace/rv/tokens/tokens.json`
Kierunki sa jawne:
Komendy zapisujące store same tworzą katalog nadrzędny, jeżeli go nie ma.
Katalog `tokens` dostaje prawa `700`, a plik `tokens.json` prawa `600`.
Kierunki są jawne:
- `sync remote r1` czyta git remote i zapisuje rekord do `tokens.json`
- `sync store r1` czyta `tokens.json` i zapisuje auth do git remota
- `update r1` nie synchronizuje sekretu, tylko odswieza metadane z API
- `update r1` nie synchronizuje sekretu, tylko odświeża metadane z API
- `remove remote r1` albo `rm remote r1` usuwa git remote
- `remove store r1` albo `rm store r1` usuwa rekord z `tokens.json`
## Listowanie
`list` pokazuje zrodla bez porownywania:
`list` pokazuje źródła bez porównywania:
```bash
./rvctl tokens list store
@@ -90,7 +93,7 @@ Znaczenie:
- `store` - rekordy zapisane w `tokens.json`
- `remote` - git remotes zapisane w `.git/config`
- `both` - oba zrodla jako osobne wiersze
- `both` - oba źródła jako osobne wiersze
Dla innego repo podaj `--repo`:
@@ -102,14 +105,14 @@ Dla innego repo podaj `--repo`:
### Remote -> Store
Uzyj, gdy token jest w git remote i chcesz go zapisac w store:
Użyj, gdy token jest w git remote i chcesz go zapisać w store:
```bash
./rvctl tokens sync remote r1
```
Ta komenda kopiuje sekret, usera, endpoint, org i repo z URL-a remota do
`tokens.json`. Nie pyta API o uprawnienia, wiec zawsze zeruje metadane API:
`tokens.json`. Nie pyta API o uprawnienia, więc zawsze zeruje metadane API:
`valid` ustawia na `?`, maski `scope`, `org_perm` i `repo_perm` ustawia na `?`,
a `expires_at` usuwa. Realne uprawnienia wpisuje dopiero:
@@ -119,27 +122,27 @@ a `expires_at` usuwa. Realne uprawnienia wpisuje dopiero:
### Store -> Remote
Uzyj, gdy token jest juz w `tokens.json`, a chcesz utworzyc albo odswiezyc git
Użyj, gdy token jest już w `tokens.json`, a chcesz utworzyć albo odświeżyć git
remote:
```bash
./rvctl tokens sync store r1
```
Jesli remote `r1` nie istnieje, `rvctl` buduje URL z pol `server.endpoint`,
`org` i `repo` w `tokens.json`, na przyklad:
Jeśli remote `r1` nie istnieje, `rvctl` buduje URL z pól `server.endpoint`,
`org` i `repo` w `tokens.json`, na przykład:
```text
http://77.90.8.171:3001/edu-tools/rv-launcher.git
```
Opcjonalnie mozna podac URL recznie:
Opcjonalnie można podać URL ręcznie:
```bash
./rvctl tokens sync store r1 --url http://77.90.8.171:3001/edu-tools/rv-launcher.git
```
Jesli remote ma juz inne credentials, uzyj:
Jeśli remote ma już inne credentials, użyj:
```bash
./rvctl tokens sync store r1 --replace
@@ -147,7 +150,7 @@ Jesli remote ma juz inne credentials, uzyj:
## Aktualizacja Metadanych
Po zapisaniu tokena w store odswiez jego metadane z API:
Po zapisaniu tokena w store odśwież jego metadane z API:
```bash
./rvctl tokens update r1
@@ -162,9 +165,9 @@ Po zapisaniu tokena w store odswiez jego metadane z API:
Ta komenda nie zmienia git remota i nie kopiuje sekretu.
## Porownanie
## Porównanie
`compare` sprawdza zgodnosc store i remote. Skrot: `cmp`.
`compare` sprawdza zgodność store i remote. Skrót: `cmp`.
```bash
./rvctl tokens compare
@@ -173,13 +176,13 @@ Ta komenda nie zmienia git remota i nie kopiuje sekretu.
Marker w kolumnie `token_ref`:
- `*` - store i remote sa zgodne
- `*` - store i remote są zgodne
- `S` - token jest tylko w store
- `R` - token jest tylko w remote
- `!` - wpis jest sparowany, ale token jest `invalid` albo wystapil blad API
- `!` - wpis jest sparowany, ale token jest `invalid` albo wystąpił błąd API
Gdy marker to `S`, token nie jest bledny. To znaczy tylko, ze nie ma
odpowiadajacego git remota.
Gdy marker to `S`, token nie jest błędny. To znaczy tylko, że nie ma
odpowiadającego git remota.
## Store-only
@@ -193,13 +196,13 @@ Po pierwszej konfiguracji wygodny tryb pracy to trzymanie tokena tylko w
```
Wtedy `compare`/`cmp` pokazuje `S`, a `list store` nadal pokazuje znane metadane
tokenu. Gdy trzeba wykonac operacje git przez remote, odtworz remote:
tokenu. Gdy trzeba wykonać operacje git przez remote, odtwórz remote:
```bash
./rvctl tokens sync store r1
```
Po operacji mozna go znowu usunac:
Po operacji można go znowu usunąć:
```bash
./rvctl tokens rm remote r1
@@ -207,7 +210,7 @@ Po operacji mozna go znowu usunac:
## Usuwanie
Usuwaj tylko to miejsce, ktore naprawde chcesz wyczyscic:
Usuwaj tylko to miejsce, które naprawdę chcesz wyczyścić:
```bash
./rvctl tokens rm remote r1
@@ -223,7 +226,7 @@ Znaczenie:
## Inne Repo
Domyslnie komendy tokenow pracuja na repo zawierajacym `rvctl`. Dla kart pracy
Domyślnie komendy tokenów pracują na repo zawierającym `rvctl`. Dla kart pracy
albo innych repo podaj `--repo`.
```bash
@@ -232,17 +235,17 @@ albo innych repo podaj `--repo`.
./rvctl tokens sync store r1 --repo ~/dev/workspace/rv/series/inf/03
```
Store tokenow nadal pozostaje jeden:
Store tokenów nadal pozostaje jeden:
```text
~/dev/workspace/rv/tokens/tokens.json
```
## Pozostale Komendy
## Pozostałe Komendy
### `tokens read`
Pokazuje zawartosc `tokens.json`.
Pokazuje zawartość `tokens.json`.
```bash
./rvctl tokens read
@@ -252,24 +255,24 @@ Pokazuje zawartosc `tokens.json`.
### `tokens add`
Dodaje szkielet rekordu do `tokens.json`. `REMOTE_ID` musi odpowiadac nazwie
git remote. Przelaczniki sa opcjonalne; jesli ich nie podasz, `rvctl` zapisuje
puste wartosci do pozniejszego uzupelnienia. Wyjatkiem jest `server`, ktory
domyslnie pochodzi z `workspace.json`.
Dodaje szkielet rekordu do `tokens.json`. `REMOTE_ID` musi odpowiadać nazwie
git remote. Przełączniki są opcjonalne; jeśli ich nie podasz, `rvctl` zapisuje
puste wartości do późniejszego uzupełnienia. Wyjątkiem jest `server`, który
domyślnie pochodzi z `workspace.json`.
```bash
./rvctl tokens add r1
./rvctl tokens add r1 --server http://77.90.8.171:3001 --user u1 --org edu-tools --repo rv-launcher
```
Najczesciej pusty szkielet ma sens wtedy, gdy chcesz recznie wpisac token w
`tokens.json`. `sync store r1` nie uzyje pustego tokena. Najpierw trzeba
uzupelnic co najmniej `value` i `user`. Jesli remote ma byc tworzony bez `--url`,
potrzebne sa tez `org` i `repo`.
Najczęściej pusty szkielet ma sens wtedy, gdy chcesz ręcznie wpisać token w
`tokens.json`. `sync store r1` nie użyje pustego tokena. Najpierw trzeba
uzupełnić co najmniej `value` i `user`. Jeśli remote ma być tworzony bez `--url`,
potrzebne są też `org` i `repo`.
### `tokens stats`
Pokazuje kontekst, tabele `tokens` i podsumowanie statusow endpointow.
Pokazuje kontekst, tabelę `tokens` i podsumowanie statusów endpointów.
```bash
./rvctl tokens stats
@@ -278,10 +281,10 @@ Pokazuje kontekst, tabele `tokens` i podsumowanie statusow endpointow.
## Uprawnienia
W `tokens.json` uprawnienia sa zapisane jako mapy klucz-wartosc. W tabelach CLI
sa pokazywane jako zwarte maski.
W `tokens.json` uprawnienia są zapisane jako mapy klucz-wartość. W tabelach CLI
są pokazywane jako zwarte maski.
Naglowki masek:
Nagłówki masek:
- `scope`: `aAimnopru`
- `org`: `oawrc-`
@@ -299,17 +302,17 @@ Kategorie `scope`:
- `r` - repository
- `u` - user
Wartosci w `scope`:
Wartości w `scope`:
- `w` - read/write
- `r` - read
- `-` - no access
- `?` - nie wczytano
- `!` - blad wczytania
- `!` - błąd wczytania
Gitea moze zwrocic globalny scope `all` zamiast listy `write:*`. Launcher
rozwija wtedy `all` do pelnej maski `wwwwwwwww`. Scope `public-only` jest
flaga ograniczenia widocznosci API i nie zmienia kategorii w tej masce.
Gitea może zwrócić globalny scope `all` zamiast listy `write:*`. Launcher
rozwija wtedy `all` do pełnej maski `wwwwwwwww`. Scope `public-only` jest
flagą ograniczenia widoczności API i nie zmienia kategorii w tej masce.
Kategorie `org_perm`:
@@ -326,17 +329,17 @@ Kategorie `repo_perm`:
- `w` - write
- `r` - read
Wartosci w `org_perm` i `repo_perm`:
Wartości w `org_perm` i `repo_perm`:
- `+` - flaga wlaczona
- `-` - flaga wylaczona
- `+` - flaga włączona
- `-` - flaga wyłączona
- `?` - nie wczytano
- `!` - blad wczytania
- `!` - błąd wczytania
## Model Danych
`tokens.json` ma format `version: 3`. Glownym rekordem jest jeden remote-token.
Pole `id` jest obowiazkowe i musi byc takie samo jak nazwa git remote, np.
`tokens.json` ma format `version: 3`. Głównym rekordem jest jeden remote-token.
Pole `id` jest obowiązkowe i musi być takie samo jak nazwa git remote, np.
`r1` albo `r1a`.
Pola synchronizowane z git remote:
@@ -351,16 +354,16 @@ Pola synchronizowane z git remote:
Pola pobierane z API przez `tokens update r1`:
- `valid` - `forever`, data wygasniecia, `invalid`, `?` albo `!`
- `valid` - `forever`, data wygaśnięcia, `invalid`, `?` albo `!`
- `scope` - mapa scope tokena
- `org_perm` - mapa praw uzytkownika w organizacji
- `repo_perm` - mapa praw uzytkownika w repo
- `org_perm` - mapa praw użytkownika w organizacji
- `repo_perm` - mapa praw użytkownika w repo
`tokens sync remote r1` nadpisuje pola z git remota i oznacza te metadane jako
nieznane. To celowe: po zmianie sekretu, usera albo repo stare metadane API nie
sa juz wiarygodne.
są już wiarygodne.
Minimalny przyklad:
Minimalny przykład:
```json
{
@@ -384,7 +387,7 @@ Minimalny przyklad:
}
```
Przyklad po `tokens update r1` moze dodatkowo zawierac:
Przykład po `tokens update r1` może dodatkowo zawierać:
```json
{
@@ -416,4 +419,4 @@ Przyklad po `tokens update r1` moze dodatkowo zawierac:
}
```
Pelny schemat pliku jest w `doc/tokens.schema.json`.
Pełny schemat pliku jest w `doc/tokens.schema.json`.