1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
|
# Ligi centralne PZBS - koordynacja
Zestaw skryptów do obsługi lig centralnych PZBS.
Podzielony na kilka modułów, każdy z nich wywoływany jako osobny *target* polecenia `make`.
Moduły czytają część konfiguracji ze zmiennych środowiskowych. Przykładowy zestaw zmiennych używanych w projekcie znajduje się w pliku `.envrc.sample`.
W repozytorium są podmoduły, pamiętaj o `git submodule update --init --recursive` po wyciągnięciu tego kodu.
## Kopie zapasowe stron z wynikami
Moduł tworzy w katalogu `http` kopie zapasowe plików wyników, ściagane z serwera. W założeniu - ma to robić bez interakcji z użytkownikiem.
Opcjonalnie, dostarcza również skryptu, który równie bezobsługowo wersjonuje zmiany w repozytorium Git.
### Wymagania wstępne
* dostęp do serwera wyników po SSH
* rsync
* opcjonalnie: git
### Wywołanie
Kopia zapasowa:
`make pull`
Kopia zapasowa z wersjonowaniem zmian:
`make autocommit`
### Konfiguracja
Zmienne środowiskowe:
* `LIGA_REMOTE_WWW_DIR`: kopletna zdalna ścieżka do backupu (`user@serwer:/ścieżka`)
* `LIGA_SSH_OPTS`: dodatkowe parametry wywołania programu `ssh` (np. wczytujące klucz prywatny do uwierzytelnienia), przekazywane do poleceń `git push` oraz `rsync`
W przypadku wersjonowania kopii zapasowych, w katalogu wyjściowym `http` musi być zainicjowane repozytorium Git ze skonfigurowanym zdalnym repozytorium docelowym.
## Kopie zapasowe baz danych turniejów
Moduł wczytuje do lokalnie skonfigurowanej bazy danych, zrzuty baz turniejów, dostarczane przez sędziów w kotłach.
Wprowadza do zrzutów często potrzebne poprawki (jak np. uzupełnienie tabeli `logoh`), a także umożliwia zdefiniowanie własnych poleceń, wykonywanych na każdej z baz danych po jej wgraniu ze zrzutu.
### Wymagania wstępne
* s3cmd
* klient MySQL
Zrzuty baz danych muszą zostać niezależnie pozyskane od sędziów poszczególnych kotłów i wrzucone do jednego wiaderka S3, np. używając [Spedytora](https://github.com/emkael/spedytor/).
### Wywołanie
`make dumps`
### Konfiguracja
Zmienne środowiskowe:
* `LIGA_MYSQL_CONNECTION_OPTS`: komplet przełączników polecenia `mysql` pozwalający podłączyć się do docelowego (lokalnego) serwera MySQL
* `LIGA_S3_BUCKET`: URI wiaderka S3, w którym trzymane są zrzuty
Pliki konfiguracyjne:
* `dumps/.s3config`: konfiguracja klienta `s3cmd`, można wygenerować ją poleceniem `s3cmd --configure -c dumps/.s3config`
* `dumps/.mapping`: mapowanie nazw plików zrzutów na docelowe bazy danych, do których zrzuty są wgrywane, każdy wiersz to jeden turniej, w każdym wierszu najpierw pojawia się nazwa bazy danych, a następnie, po odstępie, nazwa pliku relatywna względem `./dumps/` (domyślnie zrzuty trafiają do katalogu `./dumps/sync/`)
* `dumps/.queries`: spis poleceń SQL wykonywanych na każdej bazie danych po wgraniu jej do lokalnego serwera, po jednym poleceniu na wiersz
## Moduł butlera
Zbija wiele turniejów w jeden, w celu wyliczenia wspólnego butlera.
### Wymagania wstępne
* python, wersji dowolnej (testowane pod 2.7.18 i 3.8.6)
* klient MySQL
* założony prawidłowo w pakiecie JFR Teamy turniej docelowy dla wspólnej klasyfikacji (choć jego parametry startowe - liczba teamów, stołów itp. nie muszą być wcześniej poprawnie ustawione)
### Wywołanie
`make butler`
Wywołany zostanie również moduł synchronizujący i ładujący zrzuty baz danych.
Ręczne wywołanie samego scalania polega na uruchomieniu skryptu `butler/butler.py` z parametrem odpowiadającym właściwemu zestawowi zbijanych turniejów (patrz: Konfiguracja poniżej) i wgraniu wynikowego skryptu SQL do docelowego serwera bazy danych.
Na tak spreparowanym turnieju docelowym trzeba później **ręcznie** (tj. JFR Teamy Adminem) dokonać zamknęcia niezamkniętych rund (wtedy odbywa się właściwe przeliczanie łącznego butlera) oraz wysłania stron statycznych.
### Konfiguracja
Zmienne środowiskowe:
* `LIGA_MYSQL_CONNECTION_OPTS`: komplet przełączników polecenia `mysql` pozwalający podłączyć się do docelowego (lokalnego) serwera MySQL
* `LIGA_BUTLER_FINISHED_ROUND`, `LIGA_BUTLER_FINISHED_SEGMENT`: opcjonalne, jeśli ustawione, docelowy turniej cofany jest tylko do zdefiniowanego momentu, a nie do samego początku (żeby nie przeliczać wszystkich rund po kolei za każdym razem)
Plik konfiguracyjny `config.json`:
* plik formatu JSON, zawierający obiekt słownikowy
* klucz `__groups` określa nazwy "grup", tj. prefiksy, które są doklejane do nazw teamów w wynikowym turnieju, jeśli chcemy w zbiorczym butlerze rozróżnić, skąd pochodzą źródłowe drużyny - jest to prosty słownik wartości `"baza_danych": "prefiks"`
* klucz `__queries` określa dodatkowe polecenia SQL, które wykonywane są na **źródłowej** bazie danych przed poleceniami wklejającymi dane do bazy docelowej, może służyć np. do ustawienia BYEów czy korekty nierównolicznych grup, zaleca się modyfikować wyłącznie tabele, dla których w trakcie zbijania tworzone są **kopie** (prefiksowane podkreślnikiem, np. `_matches` czy `_teams`) - i działać na tych kopiach - jest to słownik formatu `"baza_danych": ["polecenie_1", "polecenie_2"]`
Pozostałe klucze słownika w `config.json` przyjmują następującą postać:
```
"identyfikator_turnieju": {
"source": [
"źródłowa_baza_danych_1",
"źródłowa_baza_danych_2",
"źródłowa_baza_danych_3"
],
"output": "docelowa_baza_danych"
}
```
W takiej konfiguracji `identyfikator_turnieju` jest parametrem wywołania skryptu `butler/butler.py`, a źródłowe turnieje zbijane są w zdefiniowanej kolejności i umeiszczane w docelowej bazie danych.
Dodatkowo, w pliku `butler/butler.py` zakładane są następujące maksymalne rozmiary turniejów źródłowych:
* zmienna `TABL_STEP` (liczba stołów w turnieju): 8
* zmienna `TEAM_STEP` (liczba teamów w turnieju): 16
* zmienna `PLAYER_STEP` (liczba zawodników w turnieju): 400
## "Australijskie" butlery
Moduł zewnętrzny, liczący i wysyłający butlery znormalizowane dla określonych turniejów.
Szczegółowa dokumentacja: [pzbs-liga-ausbutler](https://github.com/emkael/pzbs-liga-ausbutler).
### Wywołanie
`make ausbutler`
Przeliczone zostaną wszystkie butlery zdefiniowane w podmodule `pzbs-liga-ausbutler` (z katalogu `ausbutler`).
## Baza graczy
Dwa polecenia operujące na bazie zawodników.
### Konfiguracja
Zmienna środowiskowa `LIGA_PLAYERS_DB_NAME`: nazwa bazy danych JFR Players.
### Wywołania
`make players` lub `./dumps/import-players.sh`
Importuje `baza.csv` do bazy zawodników w stylu JFR. Nazwa bazy do importu czytana jest ze zmiennej środowiskowej `LIGA_PLAYERS_DB_NAME`.
`make paid`
Sprawdza status opłacenia składek wśród graczy, którzy wystąpili w turnieju teamów w danym zakresie segmentów.
Wywołuje `dumps/check-all-paid.sh`, które pobiera z `dumps/.paid-queries` argumenty do wywołania, kolejno, `dumps/check-paid.sh TURNIEJ SEGMENT_OD SEGMENT_DO`.
## Play-off
Moduł zewnętrzny, generujący i wysyłający drabinki play-off.
Szczegółowa dokumentacja: [liga-playoff](https://github.com/PZBS/liga-playoff) oraz [teamy-playoff](https://github.com/emkael/jfrteamy-playoff).
## Wymagania
* [jfrteamy-playoff](https://github.com/emkael/jfrteamy-playoff#wymagania-systemowe)
* lftp, do wysyłania drabinek
## Konfiguracja
Zmienne środowiskowe:
* `LIGA_PLAYOFF_FTP_HOST`
* `LIGA_PLAYOFF_FTP_USER`
* `LIGA_PLAYOFF_FTP_PASS`
* `LIGA_PLAYOFF_FTP_PATH`
Dane dostępu do FTP
### Wywołanie
`make playoff`
Wygenerowane i wysłane zostaną wszystkie drabinki zdefiniowane w `scripts/.groups` z podmodułu `playoff`.
|
