refactor: move handbooks to sections

astro.config.mjs

@@ -84,8 +84,8 @@ export default defineConfig({
           autogenerate: { directory: "solvro" },
         },
         {
-          label: "Handbooki",
-          autogenerate: { directory: "guides" },
+          label: "Sekcje",
+          autogenerate: { directory: "sections" },
         },
         {
           label: "Projekty",

src/content/docs/guides/Deployment.mdx → src/content/docs/sections/Devops/Deployment.mdx

@@ -1,6 +1,7 @@
 ---
 title: Deploy
 description: Jak postawić apke na naszym serwerze na coolify?
+order: 10
 ---
 
 import { Steps } from "@astrojs/starlight/components";
@@ -30,10 +31,10 @@ Link do dockerfile’a z adonisowej dokumentacji, który możecie dostosować do
 Crème de la crème, dostępny pod adresem https://devops.solvro.pl - o dostępy do zarządu
 
 _Widok projektów - wszystkie projekty postawione na Coolify_
-![](../../../assets/deployment/image8.png)
+![](../../../../assets/deployment/image8.png)
 
 _Każdy projekt ma swoje zasoby (Resources), które składają się na cały system projektu_
-![](../../../assets/deployment/image11.png)
+![](../../../../assets/deployment/image11.png)
 
 ## Baza danych
 
@@ -58,7 +59,7 @@ W naszym przypadku używamy Postgresql, tu nie ma większej filozofii, wystarczy
 
 </Steps>
 
-![](../../../assets/deployment/image14.png)
+![](../../../../assets/deployment/image14.png)
 
 Ważne dane, które będą potrzebne do envów na backendzie:
 
@@ -88,7 +89,7 @@ Ważne dane, które będą potrzebne do envów na backendzie:
 
 6. Wybieramy brancha, którego Coolify ma deployować  
     Wybieramy jak Coolify ma tworzyć obraz kontenera (zawsze **Dockerfile** przy Adonisie)
-   ![](../../../assets/deployment/image13.png)
+   ![](../../../../assets/deployment/image13.png)
 7. Czas na konfigurację 🚀
 
 </Steps>
@@ -97,26 +98,26 @@ Ważne dane, które będą potrzebne do envów na backendzie:
 
 Po udanym procesie tworzenia resource’a powinniście ujrzeć następujący widok
 
-![](../../../assets/deployment/image17.png)
+![](../../../../assets/deployment/image17.png)
 :::tip
 Po zmianach w zakładce zapisujcie zmiany, żeby potem nie wychodziły jakieś kwiatki.
 
-![](../../../assets/deployment/image2.png)
+![](../../../../assets/deployment/image2.png)
 :::
 
 Na początku warto zmienić nazwę na bardziej czytelną, zmienić domenę \{poddomena\}.solvro.pl, ewentualnie dodać opis.  
 Przykład:
-![](../../../assets/deployment/image3.png)
+![](../../../../assets/deployment/image3.png)
 
 Jeśli macie monorepo to warto też zmienić Base Directory, jeśli macie np. w jednym repo frontend i backend.  
 Przykład z [Planera](https://github.com/Solvro/web-planer) 🔥:
-![](../../../assets/deployment/image21.png)
+![](../../../../assets/deployment/image21.png)
 
 #### Network
 
 Ports Exposes jest istotny, domyślnie Adonis słucha na porcie 3333 - jeśli ustawiliście inny w env-ach to zmieńcie na ten z env-ów.  
 Porst mappings - jeśli nie macie konkretnych powodów, to nie zmieniajcie mapowania portów do hosta.
-![](../../../assets/deployment/image5.png)
+![](../../../../assets/deployment/image5.png)
 
 Zakładka Pre/Post Deployment Commands jest użyteczna, jeśli chcecie, żeby po każdym deployu jakaś akcja się wykonała - w naszym przypadku wykonujemy migracje:
 
@@ -129,25 +130,25 @@ node ace migration:run --force
 W advance’ach warto zaznaczyć Preview Deployments co pozwoli na sprawdzenie działania aplikacji po otworzeniu pull requestu na repo.
 Ostatnio (11.2024) Bartosz pisał, że automatyczne preview deployments są wyłączone i jeśli chcemy zrobić preview deployment, to musimy sobie wyklikać.
 
-![](../../../assets/deployment/image20.png)
+![](../../../../assets/deployment/image20.png)
 
 ### Preview deployments
 
-![](../../../assets/deployment/image22.png)
+![](../../../../assets/deployment/image22.png)
 
 ### Zmienne środowiskowe
 
 Kolejna ważna zakładka, Enviroment Variables - tu ustawiacie niezbędne zmienne środowiskowe.
 
-![](../../../assets/deployment/image19.png)
+![](../../../../assets/deployment/image19.png)
 
 Polecam wejść w widok developerski, przekleić envy z folderu projektu adonisa i poustawiać odpowiednie wartości:
 
-![](../../../assets/deployment/image16.png)
+![](../../../../assets/deployment/image16.png)
 
 Dane do zmiennych zaczynających się od DB\_\{zmienna\} wyciągacie z bazy którą uprzednio utworzyliście, wszystkie dane możecie wyciągnąć z URL’a bazy:
 
-![](../../../assets/deployment/image15.png)
+![](../../../../assets/deployment/image15.png)
 _**postgres://\{username\}:\{password\}@\{host\}:\{port\}/\{database\}**_
 
 Jeśli nie chcecie ręcznie przeklejać danych z url'a możecie poprosić Gepetto albo Kloda (jest to względnie bezpieczne)
@@ -156,19 +157,19 @@ Jeśli nie chcecie ręcznie przeklejać danych z url'a możecie poprosić Gepett
 
 W Sourcie mozecie wybrać brancha, którego chcecie deployować.
 
-![](../../../assets/deployment/image6.png)
+![](../../../../assets/deployment/image6.png)
 
 ### Health checks
 
 Jeśli nie chcecie mieć irytującego warningu koło statusu resource’a to możecie ustawić healthchecki [https://coolify.io/docs/knowledge-base/health-checks/](https://coolify.io/docs/knowledge-base/health-checks/)
 
-![](../../../assets/deployment/image10.png)
+![](../../../../assets/deployment/image10.png)
 
 ### Deployments
 
 Zdarzyć się może, że w trakcie deploy-u co się wykrzaczy - na ratunek przychodzi zakładka _Deployments_, w której możecie sprawdzić logi wszystkich deploy-ów i naprawić usterkę.
 
-![](../../../assets/deployment/image23.png)
+![](../../../../assets/deployment/image23.png)
 
 ### Terminal
 

src/content/docs/guides/Github.md → src/content/docs/sections/Management/Github.md

@@ -1,6 +1,8 @@
 ---
 title: Github
 description: Jak korzystać z Githuba w Solvro?
+sidebar:
+  order: 0
 ---
 
 _Działalność KN Solvro skoncentrowana jest wokół kodu, więc naturalnie nasz Github jest sercem naszej organizacji. Poniższy handbook ma przybliżyć strukturę i konwencję przyjęte na naszym GitHubie oraz przedstawić sposób i zasady pracy podczas działalności projektowej._
@@ -34,11 +36,11 @@ Dzięki publicznemu członkostwu widać Solvro na twoim profilu, a przede wszyst
 1. Wejdź na [https://github.com/orgs/Solvro/people](https://github.com/orgs/Solvro/people)
 2. Namierz siebie na liście członków i kliknij na swoją aktualną widoczność
 
-   ![informacja o prywatności członkostwa](../../../assets/github/image2.png)
+   ![informacja o prywatności członkostwa](../../../../assets/github/image2.png)
 
 3. Wybierz członkostwo publiczne, i tada! Jesteś już pełnoprawnym członkiem naszego koła.
 
-   ![opcja ustawienia publicznego członkostwa](../../../assets/github/image3.png)
+   ![opcja ustawienia publicznego członkostwa](../../../../assets/github/image3.png)
 
 ### Podaruj nam gwiazdki ⭐⭐⭐
 
@@ -47,11 +49,11 @@ Zachęcamy do gwiazdkowania naszych publicznych repozytoriów Pokażmy innym, ż
 1. Wchodzimy na listę repozytoriów. Ich publiczna liczba będzie tylko rosła (miejmy nadzieję).
 2. Wchodzimy po kolei w co fajniejsze projekty.
 
-   ![losowo wybrany projekt Solvro](../../../assets/github/image9.png)
+   ![losowo wybrany projekt Solvro](../../../../assets/github/image9.png)
 
 3. Zostawiamy gwiazdkacza ⭐\!
 
-   ![opcja gwiazdkowania repozytorium](../../../assets/github/image5.png)
+   ![opcja gwiazdkowania repozytorium](../../../../assets/github/image5.png)
 
 ## Nazewnictwo repozytoriów
 
@@ -149,7 +151,7 @@ Projekty mają wiele zaawansowanych diagramów, z których możecie korzystać w
 
 Podstawowym typem jest jednak tablica KANBAN, gdzie można dodawać zadania w formie draft, lub przypinać issues lub pull-requesty.
 
-![strona projektu](../../../assets/github/image8.png)
+![strona projektu](../../../../assets/github/image8.png)
 
 #### Flow pracy na boardzie
 
@@ -189,7 +191,7 @@ Jeśli nie rozumiesz technikaliów związanych z którymś z poniższych punktó
 
 Wchodzimy na naszą tablice zadań i przypisujemy się do zadania sygnalizując, że zgłaszamy się do jego zrobienia:
 
-![zgłaszanie się do PR](../../../assets/github/image6.png)
+![zgłaszanie się do PR](../../../../assets/github/image6.png)
 
 ### Rozpoczęcie pracy nad zadaniem
 
@@ -210,13 +212,13 @@ Wchodzimy na naszą tablice zadań i przypisujemy się do zadania sygnalizując
 1. Gdy jesteśmy gotowi, zmieniamy status taska na **In Review** (jeśli taki status jest w projekcie).
 2. Tworzymy pull requesta z naszego brancha na branch **main** lub **dev** (jeśli aplikacja na main jest już opublikowaną wersją produkcyjną).
 
-   ![przycisk otwórz PR](../../../assets/github/image7.png)
+   ![przycisk otwórz PR](../../../../assets/github/image7.png)
 
 3. Dodajemy znaczący tytuł (najlepiej powiązany z nazwą lub numerem taska/tasków) i krótko wypisujemy co zmieniliśmy lub dodaliśmy. Jeśli napotkaliśmy jakiś problem/dylemat, możemy wyjaśnić jak go rozwiązaliśmy, jakiej dokonaliśmy decyzji i dlaczego. Jeśli z jakiegoś powodu nie wykonaliśmy 100% zakresu zadania, to jest to dobre miejsce żeby o tym wspomnieć. Jeśli chcesz ładnie sformatować swój opis, obczaj [tą szybką ściągę do gh markdowna](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet).
 4. Można oznaczyć swojego techleada jako reviewer (opcjonalne).
 5. Po prawej na dole, w sekcji _Development_ możesz przypiąć **issue** (np. swoje zadanie), który zostanie automatycznie zamknięty po zmergowaniu tego pull requesta.
 
-   ![dodawanie issues do PR](../../../assets/github/image4.png)
+   ![dodawanie issues do PR](../../../../assets/github/image4.png)
 
 6. Oczekujemy na code review od naszego techleada.
 7. Przeglądamy komentarze, wprowadzamy sugestie i dyskutujemy nad rzeczami, z którymi się nie zgadzamy. Zadajemy pytania i wprowadzamy zmiany, commitujemy i pushujemy.
@@ -278,5 +280,5 @@ Uwaga: Oprócz README repozytoriów, każdy projekt (kanban board) ma też swoje
 
 To już koniec tego handbooka. Mam nadzieję, że był przydatny i aż tak bardzo nie bolał, mimo zauważalnej liczby stron. Proszę zgłaszać swoje propozycje zmiany tego dokumentu i miłego kodowania 🙂🙃🙂
 
-![Podpis Szymona Kowalińskiego](../../../assets/github/image10.png)
+![Podpis Szymona Kowalińskiego](../../../../assets/github/image10.png)
 **Wiceprezes VII Zarządu KN Solvro**