build.yml

name: Build

on:
  push:
    branches: [main, master]
  pull_request:
    branches: [main, master]
  workflow_dispatch: {}

permissions:
  contents: read

env:
  CARGO_TERM_COLOR: always
  # Ścieżki względem katalogu głównego repozytorium — te same, na które
  # wskazuje `Makefile` (`FRONTEND`/`BACKEND`).
  FRONTEND_DIR: source-code/frontend
  BACKEND_DIR: source-code/backend/src-tauri

jobs:
  # Odpowiednik `make frontend`: `cd source-code/frontend && npm install
  # && npm run build`. Osobny, pierwszy job — zarówno `cargo check`, jak i
  # `cargo build` w backendzie WYMAGAJĄ istnienia
  # `source-code/frontend/dist` (patrz `frontendDist` w `tauri.conf.json`,
  # który Tauri osadza w binarce przy kompilacji), więc backend nie może
  # ruszyć bez tego kroku — stąd `needs: frontend` w obu kolejnych jobach
  # i przekazanie zbudowanego `dist/` jako artefaktu między nimi zamiast
  # budowania frontendu od nowa w każdym jobie osobno.
  frontend:
    name: Frontend (Solid.js + TypeScript)
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "22"
          # BUGFIX (zgłoszony przez prawdziwy przebieg workflow —
          # `logs_90262718923.zip`): wbudowany cache `setup-node`
          # (`cache: npm` + `cache-dependency-path`) TWARDO failuje całym
          # krokiem („Some specified paths were not resolved, unable to
          # cache dependencies”), jeśli podana ścieżka nie da się
          # rozwiązać do ŻADNEGO pliku — co ubiło cały job (i przez
          # `needs: frontend` też job `backend`, który przez to nawet się
          # nie zaczął), zanim `npm install`/testy/build w ogóle
          # ruszyły. Zamiast polegać na tym wbudowanym mechanizmie
          # (kruchym akurat na brak/niespójną ścieżkę `package-lock.json`
          # w repo), cache'owanie robimy osobnym, odpornym krokiem niżej
          # (`actions/cache`, który przy braku pliku po prostu nie
          # trafia w cache, zamiast przerywać workflow błędem).

      - name: Cache npm
        uses: actions/cache@v4
        with:
          path: ~/.npm
          # `hashFiles` na NIEISTNIEJĄCY plik zwraca pusty string (nie
          # błąd) — klucz wtedy po prostu nie zawiera tego segmentu,
          # cache się nie trafi (zamiast crashować cały krok, jak robił
          # to wbudowany mechanizm `setup-node` wyżej).
          key: npm-${{ runner.os }}-${{ hashFiles(format('{0}/package-lock.json', env.FRONTEND_DIR)) }}
          restore-keys: |
            npm-${{ runner.os }}-

      # `npm ci` wymaga OBECNOŚCI i pełnej spójności `package-lock.json`
      # (inaczej sam odmawia startu) — skoro nie mamy pewności, czy ten
      # plik jest zacommitowany w repo (patrz bugfix wyżej), robimy to
      # odpornie: `npm ci`, gdy lockfile jest; w przeciwnym razie zwykłe
      # `npm install` (samo sobie ustali/zapisze wersje). Warto mimo to
      # ZACOMMITOWAĆ `source-code/frontend/package-lock.json` w repo,
      # jeśli go tam jeszcze nie ma — to jedyny sposób na w pełni
      # reprodukowalne wersje zależności frontendu między przebiegami.
      - name: npm install
        working-directory: ${{ env.FRONTEND_DIR }}
        run: |
          if [ -f package-lock.json ]; then
            echo "Znaleziono package-lock.json — npm ci"
            npm ci
          else
            echo "::warning::Brak package-lock.json w ${{ env.FRONTEND_DIR }} — używam npm install zamiast npm ci (mniej reprodukowalne; warto zacommitować lockfile)."
            npm install
          fi

      # Odpowiednik `make check` (część frontendowa: `npm run check`) —
      # `tsc --noEmit`, bez emitowania plików, tylko sprawdzenie typów.
      # Uruchamiane PRZED `npm run build`, żeby błąd typów przerwał
      # workflow zanim zdąży zmarnować czas na sam build.
      - name: Sprawdzenie typów (tsc --noEmit)
        working-directory: ${{ env.FRONTEND_DIR }}
        run: npm run check

      - name: Build (tsc -b && vite build)
        working-directory: ${{ env.FRONTEND_DIR }}
        run: npm run build

      - name: Upload dist/ jako artefakt dla joba backend
        uses: actions/upload-artifact@v4
        with:
          name: frontend-dist
          path: ${{ env.FRONTEND_DIR }}/dist
          retention-days: 1

  # Odpowiednik `make check` (część backendowa: `cargo check --workspace`)
  # + `make test` (`cargo test -p hacker-mode-ipc && cargo test -p
  # hacker-mode`) + `make backend` (`cargo build --release --workspace`) —
  # w tej samej kolejności, w jednym jobie (żeby nie instalować systemowych
  # zależności Tauri i nie kompilować od zera zależności Rust trzykrotnie
  # w trzech osobnych jobach).
  backend:
    name: Backend (Rust workspace)
    runs-on: ubuntu-latest
    needs: frontend
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Pobierz zbudowany frontend/dist
        uses: actions/download-artifact@v4
        with:
          name: frontend-dist
          path: ${{ env.FRONTEND_DIR }}/dist

      # Zależności systemowe Tauri v2 na Ubuntu/Debian — ten sam zestaw,
      # co README opisuje dla Arch/pacman
      # (`webkit2gtk-4.1 gtk3 libayatana-appindicator librsvg`), tylko
      # nazwami pakietów `apt` zamiast `pacman` (runnery GitHub Actions są
      # oparte na Ubuntu). `pkg-config`/`build-essential` dorzucone jawnie,
      # mimo że zwykle są już obecne na obrazie `ubuntu-latest` — nie
      # warto polegać na tym cicho.
      - name: Zależności systemowe (Tauri v2 / Ubuntu)
        run: |
          sudo apt-get update
          sudo apt-get install -y \
            build-essential \
            pkg-config \
            libssl-dev \
            libgtk-3-dev \
            libwebkit2gtk-4.1-dev \
            libayatana-appindicator3-dev \
            librsvg2-dev \
            patchelf

      - name: Rust toolchain (stable)
        uses: dtolnay/rust-toolchain@stable

      # Cache'uje `~/.cargo/registry`, `~/.cargo/git` i `target/` między
      # uruchomieniami workflow, kluczowane po zawartości `Cargo.lock`
      # (jeśli obecny — patrz CHANGELOG 0.9.2, `Cargo.lock` bywa usuwany
      # jako nieaktualny; brak pliku nie jest błędem, `Swatinem/rust-cache`
      # radzi sobie też bez niego, po prostu z szerszym kluczem cache).
      - name: Cache Cargo
        uses: Swatinem/rust-cache@v2
        with:
          workspaces: ". -> target"

      # `--locked` NIE jest tu używane — `Cargo.lock` w repo bywa
      # nieaktualny względem `Cargo.toml` (patrz CHANGELOG: generowany w
      # środowisku ze starym `rustc` 1.75, który nie potrafi w pełni
      # rozwiązać współczesnego drzewa zależności — np. `mail-parser`
      # przez `ribbit-client` wymaga dziś `edition2024`). Próba `--locked`
      # kończyła się tu za każdym razem błędem „cannot create the lock
      # file … because --locked was passed to prevent this”, zanim i tak
      # trzeba było spaść do zwykłego `cargo check` bez tej flagi (patrz
      # `logs_Hacker-Mode.zip`) — usunięte, żeby nie generować mylącego
      # błędu w logu za KAŻDYM przebiegiem workflow na nowoczesnym
      # `cargo` (który i tak sobie z tym radzi, po prostu aktualizując
      # lock w locie, dokładnie tak jak poniższe `cargo test`/`cargo
      # build` już robią bez `--locked`).
      - name: cargo check --workspace
        run: cargo check --workspace

      # Odpowiednik `make test`. Dwa osobne wywołania (nie jedno
      # `cargo test --workspace`) — tak samo jak `Makefile`, żeby log
      # błędu jednoznacznie wskazywał, w którym pakiecie testy nie
      # przeszły, zamiast przemieszanego wyjścia obu naraz.
      - name: cargo test -p hacker-mode-ipc
        run: cargo test -p hacker-mode-ipc

      - name: cargo test -p hacker-mode
        run: cargo test -p hacker-mode

      # Odpowiednik `make backend` (`cargo build --release --workspace`) —
      # buduje `hacker-mode` (`source-code/backend/src-tauri`) i
      # `hacker-mode-ipcctl` (`ipc`), plus `ea-cli`/`bnet` jako
      # zależności statycznie linkowane do `hacker-mode` (patrz komentarz
      # w głównym `Cargo.toml`).
      - name: cargo build --release --workspace
        run: cargo build --release --workspace

      - name: Upload zbudowanych binarek
        uses: actions/upload-artifact@v4
        with:
          name: hacker-mode-linux-x86_64
          path: |
            target/release/hacker-mode
            target/release/hacker-mode-ipcctl
          retention-days: 14