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
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
|
# 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)
* `LIGA_BUTLER_TABLE_STEP`, `LIGA_BUTLER_TEAM_STEP` i `LIGA_BUTLER_PLAYER_STEP` (opcjonalne) definiują, o ile podbijane są dla każdego kolejnego zbijanego turnieju bazodanowe ID stołów, teamów i graczy - numeracja stołów i teamów po tej operacji musi być ciągła
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, możliwe do przesłonięcia zmiennymi środowiskowymi `LIGA_BUTLER_*_STEP`:
* 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 teams`
Sprawdza przynależność graczy do drużyn, wg przypisania w Cezarze. Wymaga CSVki w specyficznym formacie, zawierającej ID drużyn z Cezara. Jej URL ustawia się dla `import-players.sh`, w zmiennej `LIGA_BAZA_CSV`. Mapowanie drużyn w bazach danych turniejów odbywa się przy pomocy plików `.dumps/.cezar-teams-*`.
Wywołuje `dumps/check-all-teams.sh`, które pobiera z `dumps/.paid-queries` argumenty do wywołania, kolejno, `dumps/check-teams.sh TURNIEJ`.
`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`.
`make lineups`
Sprawdza poprawność lineupów oraz spójność lineupów z tabelą `butler` w turniejach.
Wywołuje `dumps/check-all-lineups.sh`, które pobiera z `dumps/.paid-queries` argumenty do wywołania, kolejno, `dumps/check-lineups.sh TURNIEJ`.
`make checks`
Wywołuje kolejno `paid`, `teams` i `lineups`.
## Strona z rozkładami
Generator plików dla strony z rozkładami do publikacji przy wynikach.
### Wymagania
* [deal-convert](https://github.com/emkael/deal-convert) (uwaga: Python 2.x!) wraz z podmodułami
* lftp, do wysyłania wygenerowanych stron
### Konfiguracja
Zmienne środowiskowe:
* `LIGA_BOARDS_DEAL_CONVERT_PATH` - ścieżka do `deal-converter.py`
* `LIGA_BOARDS_FTP_ENABLED` - włącza synchronizację przez FTP
* `LIGA_BOARDS_FTP_PATH` - ścieżka na serwerze zdalnym
* `LIGA_FTP_HOST`, `LIGA_FTP_USER`, `LIGA_FTP_PASS`
Pliki JSON w `boards/config` - definiują, które pliki PBN z `boards/pbns` mają zostać przetworzone i wyświetlone na stronie. Generowane są strony dla każdego z obecnych tam plików `*.json`, z osobna, przyjmując jego nazwę jako identyfikator.
Szablony stron rozkładów można zdefiniować w `boards/template/IDENTYFIKATOR.html`. Do zaślepki `<!---[LOGOH]--->` wpisywana jest zawartość pliku `boards/template/IDENTYFIKATOR.logo.html.
### Wywołania
`make records` lub `./boards/run.sh`
## 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_FTP_HOST`
* `LIGA_FTP_USER`
* `LIGA_FTP_PASS`
* `LIGA_PLAYOFF_FTP_PATH`
* `LIGA_PLAYOFF_LOGFILE`
Dane dostępu do FTP
### Wywołanie
`make brackets`
Wygenerowane i wysłane zostaną wszystkie drabinki zdefiniowane w `scripts/.groups` z podmodułu `playoff`.
|
