Workflow: Trying workflow on master branch #1

Merged
htamas1210 merged 6 commits from Workflow into master 2025-11-05 14:49:08 +01:00
7 changed files with 210 additions and 0 deletions

93
.github/workflows/dispatcher.yml vendored Normal file
View File

@@ -0,0 +1,93 @@
name: Dispatcher
on:
push:
branches:
- '**'
jobs:
dispatch:
runs-on: self-hosted
outputs:
engine: ${{ steps.check.outputs.engine }}
server: ${{ steps.check.outputs.server }}
ui: ${{ steps.check.outputs.ui }}
steps:
- name: Determine which tests to run
id: check
run: |
BRANCH="${{ github.ref_name }}"
echo "Branch: $BRANCH"
ENGINE=false
SERVER=false
UI=false
if [[ "$BRANCH" == *"Engine"* ]]; then
ENGINE=true
fi
if [[ "$BRANCH" == *"Server"* ]]; then
SERVER=true
fi
if [[ "$BRANCH" == *"UI"* ]]; then
UI=true
fi
# Run all on master
if [[ "$BRANCH" == "master" ]]; then
ENGINE=true
SERVER=true
UI=true
fi
echo "engine=$ENGINE" >> $GITHUB_OUTPUT
echo "server=$SERVER" >> $GITHUB_OUTPUT
echo "ui=$UI" >> $GITHUB_OUTPUT
- name: Trigger Engine Test
if: steps.check.outputs.engine == 'true'
uses: actions/github-script@v7
with:
script: |
github.rest.actions.createWorkflowDispatch({
owner: context.repo.owner,
repo: context.repo.repo,
workflow_id: 'engine_test.yml',
ref: '${{ github.ref }}',
inputs: {
triggered_by: 'dispatch.yml',
branch: '${{ github.ref_name }}'
}
})
- name: Trigger Server Test
if: steps.check.outputs.server == 'true'
uses: actions/github-script@v7
with:
script: |
github.rest.actions.createWorkflowDispatch({
owner: context.repo.owner,
repo: context.repo.repo,
workflow_id: 'server_test.yml',
ref: '${{ github.ref }}',
inputs: {
triggered_by: 'dispatch.yml',
branch: '${{ github.ref_name }}'
}
})
- name: Trigger UI Test
if: steps.check.outputs.ui == 'true'
uses: actions/github-script@v7
with:
script: |
github.rest.actions.createWorkflowDispatch({
owner: context.repo.owner,
repo: context.repo.repo,
workflow_id: 'ui_test.yml',
ref: '${{ github.ref }}',
inputs: {
triggered_by: 'dispatch.yml',
branch: '${{ github.ref_name }}'
}
})

22
.github/workflows/engine_test.yml vendored Normal file
View File

@@ -0,0 +1,22 @@
name: Engine Tests
on:
workflow_dispatch:
jobs:
engine-tests:
runs-on: self-hosted
steps:
- uses: actions/checkout@v4
- name: Set up Rust
uses: actions/setup-rust@v1
with:
rust-version: stable
- name: Run Engine tests
run: |
cd engine
pwd
cargo test --verbose

22
.github/workflows/server_test.yml vendored Normal file
View File

@@ -0,0 +1,22 @@
name: Server Tests
on:
workflow_dispatch:
jobs:
server-tests:
runs-on: self-hosted
steps:
- uses: actions/checkout@v4
- name: Set up Rust
uses: actions/setup-rust@v1
with:
rust-version: stable
- name: Run Server tests
run: |
cd server
pwd
cargo test --verbose

22
.github/workflows/ui_test.yml vendored Normal file
View File

@@ -0,0 +1,22 @@
name: UI Tests
on:
workflow_dispatch:
jobs:
ui-tests:
runs-on: self-hosted
steps:
- uses: actions/checkout@v4
- name: Set up Rust
uses: actions/setup-rust@v1
with:
rust-version: stable
- name: Run UI tests
run: |
cd ui
pwd
cargo test --verbose

51
Docs/funk_spec.md Normal file
View File

@@ -0,0 +1,51 @@
## 5. Követelménylista
### Szerver
| Név | Verzió | Leírás |
| --- | ------ | ------ |
| **WebSocket** | 1.0 | A szerver és a kliens között folyamatos kétirányú kommunikációt biztosít. A kapcsolat létrejötte után a szerver valós időben képes fogadni és továbbítani az eseményeket (pl. lépés végrehajtása, állapotfrissítés). Hiba esetén a kapcsolat automatikusan újraépül. |
| **Kapcsolatok csoportosítása** | 1.0 | A szerver figyeli az elérhető, szabad klienseket, majd két szabad kapcsolatot automatikusan összerendel egy meccsbe. A csoportosítás után a játékosok azonos „room”-ba kerülnek, és a szerver biztosítja az egymás közötti adatkommunikációt. |
| **Kommunikáció az engine-nel** | 1.0 | A szerver a játékosoktól érkező lépéseket és játékinformációkat továbbítja az engine-nek feldolgozásra. Az engine válasza után a szerver visszaküldi az eredményt a klienseknek (pl. érvényes lépés, matt, patt). A kommunikáció aszinkron módon zajlik, válaszidő-ellenőrzéssel. |
| **Kommunikáció a UI-al** | 1.0 | A szerver WebSocket-en keresztül adatokat továbbít a felhasználói felület és az engine között. A UI által kért műveletek (pl. új meccs létrehozása, állapotlekérés) feldolgozását a szerver közvetíti.|
### Engine
| Név | Verzió | Leírás |
| --- | ------ | ------ |
| **Bitboard** | 1.0 | A játék táblaállapotát bitműveletekkel reprezentálja a hatékonyság érdekében. Minden bábu típus és szín külön bitmask-on kerül tárolásra, lehetővé téve a gyors lekérdezéseket és lépésellenőrzéseket. |
| **Lépésgenerálás LUT** | 1.0 | Előre kiszámított lookup táblák segítségével gyorsítja a lépésgenerálást és szabályellenőrzést. Ez csökkenti a számítási időt, és optimalizálja az engine teljesítményét. |
| **Lépésgenerálás** | 1.0 | A különböző bábutípusok (gyalog, bástya, futó, stb.) lépési logikáját valósítja meg. A függvények ellenőrzik a lépés érvényességét, figyelembe véve az aktuális állást, sakkhelyzetet és speciális szabályokat (pl. sáncolás, en passant). |
| **Util függvények** | 1.0 | Segédfüggvények az engine belső működéséhez, például raycast műveletek, bitműveleti maszkok kezelése, valamint logikai ellenőrzések a lépések és ütések számításához. |
### UI
| Név | Verzió | Leírás |
| --- | ------ | ------ |
| **Belépés** | 1.0 | A felhasználó a kezdőképernyőn keresztül adhatja meg a nevét lokális játékhoz, vagy hitelesítheti magát online játékmód esetén. Hibás adatok esetén a rendszer figyelmeztetést küld. |
| **Főmenü** | 1.0 | Az alkalmazás központi navigációs felülete, ahol a felhasználó meccset kereshet, új játékot indíthat lokálisan, vagy beállításokat módosíthat. A menü megjeleníti az aktuális státuszt (online/offline). |
| **Játék** | 1.0 | A játékfelület megjeleníti a táblát, bábukat, lépéseket, és az aktuális játékállást. Támogatja mind az online, mind a lokális módot. A felület kezeli az interakciókat (lépéskattintás, visszavonás, végeredmény kijelzés). |
| **Kommunikáció a szerverrel** | 1.0 | A kliens a szerveren keresztül kommunikál az engine-nel. A UI felel az üzenetek küldéséért (lépés, új játék, visszajelzés), valamint a szervertől kapott események vizuális megjelenítéséért. |
### GitHub Actions (CI/CD)
| Név | Leírás |
| --- | ------ |
| Folyamatos tesztelés | A projekt minden commit után automatikusan tesztelődik. A pipeline lefuttatja a teszteket, és értesítést küld hibás build esetén. |
| Folyamatos integráció | Az új funkciók beolvadásakor a rendszer automatikusan integrálja a változtatásokat, új buildet hoz létre, és frissíti a fejlesztői környezetet. |
| Tesztadatok | A tesztadatok legyenek elérhetőek egy táblázatban, dátummal ellátva. (Google Sheets) |
## A github workflow folyamata:
A githubon tárolt kód minden feltöltésnél a kód mindig automatikus tesztelve van, egy workflow által. Ennek a működése:
1. A brancheket a következő képpen kell elnevezni: Projekt/task_neve (a task neve a kanban tablabol jon).
2. 3 projekt van a github repository-ban: Engine, Server és a UI. Ennek megfelelően a következőképpen kell kinézniük a brancheknek:
- Engine/task_1
- Server/task_1
- UI/task_1
Erre azért van szükség mert a github workflow ezek alapján az elnevezések alapján fogja eldönteni melyik teszteket futtassa. Ha az Engine projekthez lett feltöltve kód, akkor csak az ahhoz tartozó teszteket futtassa.
3. A workflow folyamat a következő:
Amikor feltöltődik a három projekt közül valamelyikére egy új commit. A github workflow megnézni mi a branch neve. Ezután letölti a projektet githubról, és lefuttatja azon projekt teszteit. A tesztek eredményét feltölti egy google táblazat fájlba, ahonnan bármikor visszenézhető. Minden teszt eredmény az annak megfelően elnevezett munkalapra kerül be (Engine, Server, UI), egymás alá táblázatos elrendezésben. Az oszlopok a következőek: Dátum, függvény neve, teszt bemenet, teszt kimenet, sikeres-e.
Amikor a main/master branchre kerül fel kód. A teszt az előbbiek alapján ugyanúgy lefut, csak itt mind a 3 projekt tesztje le fog futni és az eredmény egy main/master nevű munkalapra fog feltöltődni a táblázatban. Amint sikeresen lefut a tesztelés, elindul egy automatikus build, ami le fogja build-elni a projekteket. Ezután létrehoz egy új Release-t githubon, ahol beállítja a verzió számot a rust projektben beállított verzió számra, majd feltölti oda a fájlokat amiket a build hozott létre, és kiteszi ezt a buildet.
A workflow 3 külön fáljba van bontva:
1. A dispatcher (dispatch.yml). Ez indítja el a workflow-t ami teszteli a kódot a megfelelő branchen, elindítja a release workflow-t ami feltölti a master branchről buildelt projekt fájlokat.
2. A teszter (tests.yml). Ez a workflow bele fog lépni a megfelelő projekt mappába és lefutattja a megírt teszteket, és feltölti az eredményt egy google spreadsheet-be.
3. A release (release.yml). Amint sikeresek a tesztek elindul ez a workflow és lefordítja a kódot majd feltölti github-ra egy új release-ként

View File