Kopia lustrzana repozytorium autora, testy i budowa QPKG: CI na Twoim NAS

Forgejo na Twoim NAS prowadzi lustro pull repozytorium programu. Własny projekt pakietowania buduje codziennie najnowsze wydanie autora, uruchamia jego testy i tworzy z niego QPKG, na własnym runnerze NAS. Przykładem jest fzy, mały wyszukiwacz rozmyty napisany w C (licencja MIT).

1. ModułyGit, CI, Edytor
2. Lustrorepozytorium autora
3. Projektnowy projekt, pakiet QPKG
4. Przepływ pracypobranie, testy, budowa
5. Uruchomieniacodziennie, przy wypchnięciu, ręcznie

Zrzuty ekranu pochodzą z panelu Bucket & Code Server IDE i z jego Forgejo. Pola wypełniono tak, jak opisuje poradnik. Konto nazywa się ola.

01Zanim zaczniesz

• Git, CI i Edytor muszą być włączone. Wyłączony moduł ma przycisk na swoim kafelku na stronie Przegląd i na własnej stronie: Włącz Git, Włącz Edytor, a także Włącz Git i CI, gdy Git jest jeszcze wyłączony.
• Potrzebny jest QDK: na stronie Toolchainy, na zakładce QNAP, zainstaluj QNAP QDK 2.5.0.
• Potrzebne jest środowisko budowania Ubuntu 24.04: utworzysz je na stronie Aplikacje → Przykłady albo przyciskiem Utwórz środowisko Builder na stronie Nowa aplikacja. W tym środowisku buduje przepływ pracy.
• NAS musi mieć dostęp do internetu: actions/checkout i actions/upload-artifact pochodzą z data.forgejo.org, a lustro pobiera dane z serwera autora.

Runner na NAS-ie przyjmuje zadania, których pole runs-on podaje jedną z jego etykiet, na przykład bucketvs. Każde zadanie wykonuje na samym NAS-ie, jako administrator. Kto może wypchnąć przepływ pracy do repozytorium, może więc uruchamiać na NAS-ie polecenia jako administrator. Dlatego prawo zapisu dawaj tylko osobom, którym możesz powierzyć hasło administratora NAS-a.

02Lustrzane odbicie repozytorium autora

1. W Forgejo (Otwórz Forgejo na stronie Git) naciśnij + → Nowa migracja → Git.
2. Wklej adres repozytorium autora, tutaj https://github.com/jhawthorn/fzy.git, zaznacz To repozytorium będzie lustrem, nadaj nazwę, na przykład fzy-upstream, i naciśnij Migruj repozytorium.
3. Lustro samo pobiera commity i tagi autora. Na stronie Ustawienia lustra jest Interwał lustra (domyślnie 8 godzin, najmniej 10 minut) i przycisk Synchronizuj teraz.

Do lustra nie da się nic wypchnąć, więc nie umieścisz w nim własnego przepływu pracy. Synchronizacja uruchamia tylko przepływy pracy, które autor ma w swoim repozytorium w .forgejo/workflows/, a fzy nie ma żadnego. Dlatego budowanie umieszczasz we własnym repozytorium, które czyta z lustra.

03Własny projekt pakietowania

Otwórz kreator Nowy projekt ze strony Git albo z palety poleceń (potrzebna rola developer). Wszystkie kroki opisuje poradnik Własne App Center. W tym przykładzie wybierz:

1. Szablon: Pakiet QPKG.
2. Nazwa: fzy. Usługa: Narzędzie wiersza poleceń, które podczas działania pakietu dowiązuje program do /usr/bin.
3. Środowisko budowania: ubuntu2404-builder, to samo, którego używa przepływ pracy.
4. Naciśnij Utwórz projekt. Projekt dostaje swoje repozytorium, folder projects/fzy i przepływ pracy z szablonu. W sekcji 05 zastąpisz go własnym.

W repozytorium utworzonym przed włączeniem CI funkcja Actions w Forgejo jest wyłączona i wypchnięty przepływ pracy niczego nie uruchamia. Włączysz ją w Ustawienia repozytorium → Jednostki. Repozytoria utworzone przy włączonym CI mają ją już włączoną.

04Token tylko do odczytu dla lustra

Zadanie klonuje lustro przez HTTPS. Klonowanie wymaga logowania, chyba że lustro jest publiczne i włączone jest Publiczne przeglądanie. Dlatego przepływ pracy podaje przy klonowaniu token, który pozwala tylko czytać.

1. W Forgejo otwórz Ustawienia → Aplikacje → Wygeneruj nowy token. Podaj nazwę, na przykład mirror-read, i uprawnienie repozytorium: Read. Skopiuj token od razu, bo Forgejo pokazuje go tylko raz.
2. W repozytorium pakietu otwórz Ustawienia → Działania → Secrets → Add secret. Jako nazwę wpisz MIRROR_TOKEN, a jako wartość token.

05Workflow

Zapisz ten plik w projekcie jako .forgejo/workflows/build.yml, zamiast pliku z szablonu, i wypchnij go. Przepływ pracy uruchamia się przy każdym wypchnięciu, raz dziennie i ręcznie.

# .forgejo/workflows/build.yml: fzy from the author's newest release, tested, as a QPKG
name: build
on:
  push:
  schedule:
    - cron: '30 4 * * *'
  workflow_dispatch:
jobs:
  build:
    runs-on: bucketvs
    steps:
      - uses: actions/checkout@v4
      - name: The author's newest release, from the mirror
        run: |
          git -c http.extraHeader="Authorization: token $MIRROR_TOKEN" clone --quiet \
            "${{ github.server_url }}/${{ github.repository_owner }}/fzy-upstream.git" upstream
          tag=$(git -C upstream describe --tags --abbrev=0)
          git -C upstream checkout --quiet "$tag"
          echo "VERSION=${tag#v}" >> "$GITHUB_ENV"
        env:
          MIRROR_TOKEN: ${{ secrets.MIRROR_TOKEN }}
      - name: Build and run the author's tests
        run: |
          bvs env run ubuntu2404-builder -- make -C upstream
          bvs env run ubuntu2404-builder -- make -C upstream check
      - name: Put the program into the package
        run: |
          rm -f shared/bin/fzy
          install -D -m 755 upstream/fzy x86_64/bin/fzy
          sed -i "s/^QPKG_VER=.*/QPKG_VER=\"$VERSION\"/" qpkg.cfg
      - name: Build the QPKG
        run: bvs qbuild
      - uses: actions/upload-artifact@v3
        with:
          name: fzy-qpkg
          path: build/*.qpkg
      - name: Publish into this NAS's App Center repository
        run: |
          for f in build/*.qpkg; do
            if out=$(bvs repo publish "$f" --arch x86_64 --latest 2>&1); then
              echo "$out"
            elif printf '%s' "$out" | grep -q 'carries no code signature'; then
              echo "::warning::$f is built but not published: it carries no code signature"
            else
              echo "$out" >&2
              exit 1
            fi
          done

• Drugi krok pobiera najnowszy tag z lustra. Dzięki temu pakiet nadąża za wydaniami autora, a numer wydania staje się wersją pakietu (QPKG_VER).
• bvs env run ubuntu2404-builder -- … buduje i testuje w środowisku, z jego kompilatorem i bibliotekami. Nieudany test kończy zadanie błędem i nic nie zostaje spakowane.
• bvs qbuild buduje pakiet w folderze build/. Gotowy pakiet zostaje zapisany przy uruchomieniu jako artefakt.
• Ostatni krok publikuje pakiet do repozytorium App Center na NAS-ie, które przyjmuje tylko podpisane pakiety. Bez certyfikatu zadanie kończy się ostrzeżeniem, a pakiet zostaje tylko artefaktem. Poradnik Własne App Center pokazuje dwa kroki, które podpisują każdą zbudowaną wersję.

06Uruchomienia, testy i pakiet

Zakładka Działania w repozytorium pokazuje każde uruchomienie i jego przyczynę: wypchnięcie, harmonogram albo osobę, która je uruchomiła.

Strona uruchomienia pokazuje każdy krok i jego czas. Krok z testami wypisuje wyniki testów autora.

Przycisk Run workflow uruchamia przepływ pracy ręcznie, na przykład zaraz po Synchronize now w lustrze. Pakiet jest w sekcji Artifacts na stronie uruchomienia.