Replica il Git dell'autore, esegui i test, crea un QPKG: CI sul tuo NAS

Forgejo sul tuo NAS mantiene una replica pull del repository di un programma. Un progetto di pacchettizzazione tuo compila ogni giorno l'ultima release dell'autore, esegue i test dell'autore e ne crea un QPKG, sul runner del NAS stesso. L'esempio è fzy, un piccolo fuzzy finder scritto in C (licenza MIT).

1. ModuliGit, CI, l'Editor
2. Replicail repository dell'autore
3. ProgettoNuovo progetto, pacchetto QPKG
4. Workflowrecupero, test, build
5. Esecuzioniogni giorno, a un push, a mano

Le immagini provengono dal pannello e da Forgejo di Bucket & Code Server IDE, con ogni campo compilato come descrive questa guida. L'account si chiama ola.

01Prima di cominciare

• Git, CI e l'Editor devono essere attivi. Un modulo spento ha un pulsante sulla sua scheda nella pagina Panoramica e nella propria pagina: Attiva Git, Attiva Editor e Attiva Git e CI finché Git è ancora spento.
• QDK deve essere installato: nella pagina Toolchain, scheda QNAP, installa QNAP QDK 2.5.0.
• Ti serve l'ambiente di build Ubuntu 24.04: App → Esempi, oppure Crea un ambiente Builder nella pagina Nuova app. Il workflow compila in questo ambiente.
• Il NAS deve poter accedere a internet: actions/checkout e actions/upload-artifact vengono da data.forgejo.org, e la replica scarica dal server dell'autore.

Il runner sul NAS prende i job il cui runs-on indica una delle sue etichette, come bucketvs. Esegue ogni job sul NAS stesso, come admin. Chi può fare push di un workflow in un repository può quindi eseguire comandi come admin sul NAS: concedi l'accesso in push solo a persone a cui affideresti la password admin del NAS.

02Replica il repository dell'autore

1. In Forgejo (Apri Forgejo nella pagina Git) premi + → Nuova migrazione → Git.
2. Incolla l'indirizzo del repository dell'autore, qui https://github.com/jhawthorn/fzy.git, spunta Questo repository sarà una replica, dagli un nome, ad esempio fzy-upstream, e premi Migra repository.
3. La replica scarica da sola i commit e i tag dell'autore. Le sue Impostazioni mostrano l'Intervallo di replica (8 ore se non lo cambi, almeno 10 minuti) e Sincronizza ora.

Una replica rifiuta i push, quindi non puoi metterci il tuo workflow. Una sincronizzazione esegue solo i workflow che il repository dell'autore stesso contiene in .forgejo/workflows/, e fzy non ne ha. Per questo la build sta in un repository tuo, che legge la replica.

03Un progetto di pacchettizzazione tuo

Apri Nuovo progetto dalla pagina Git o dalla palette dei comandi (ruolo sviluppatore). La guida Il tuo App Center illustra ogni passaggio; per questo esempio:

1. Modello: Pacchetto QPKG.
2. Nome: fzy. Servizio: Strumento da riga di comando, che collega il programma in /usr/bin mentre il pacchetto è in esecuzione.
3. Ambiente di compilazione: ubuntu2404-builder, l'ambiente che usa il workflow.
4. Premi Crea il progetto. Il progetto riceve il suo repository, la cartella projects/fzy e il workflow del modello, che la sezione 05 sostituisce.

Un repository creato prima che CI fosse attivo ha le Actions di Forgejo disattivate, e un workflow inviato non avvia nulla. Attivale in Impostazioni → Unità del repository; i repository creati con CI attivo le hanno già attive.

04Un token di sola lettura per la replica

Il job clona il mirror tramite HTTPS. Se il mirror non è pubblico, o se Navigazione pubblica è disattivata, quel clone richiede un accesso, e il workflow usa per questo un token che può solo leggere.

1. In Forgejo, Impostazioni → Applications → Generate new token: un nome come mirror-read, il permesso repository: Read. Copia il token: Forgejo lo mostra una sola volta.
2. Nel repository di pacchettizzazione, Impostazioni → Azioni → Secrets → Add secret: il nome MIRROR_TOKEN e il token come valore.

05Il workflow

Inserisci questo file nel progetto come .forgejo/workflows/build.yml, al posto di quello del modello, e fai push. Viene eseguito a ogni push, una volta al giorno e manualmente.

# .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

• Il secondo passaggio prende l'ultimo tag del mirror, così il pacchetto segue le release dell'autore, e la sua versione diventa quella del pacchetto (QPKG_VER).
• bvs env run ubuntu2404-builder -- … compila e testa all'interno dell'ambiente, con il suo compilatore e le sue librerie. Un test fallito fa fallire l'esecuzione e non viene impacchettato nulla.
• bvs qbuild compila il pacchetto in build/. L'esecuzione lo conserva come artefatto.
• L'ultimo passaggio pubblica nel repository App Center del NAS, che accetta solo pacchetti con firma del codice. Senza certificato l'esecuzione termina con un avviso e il pacchetto resta un artefatto. La guida Il tuo App Center mostra i due passaggi che firmano ogni build.

06Esecuzioni, test e pacchetto

La scheda Azioni del repository elenca ogni esecuzione con ciò che l'ha avviata: un push, la pianificazione o una persona.

Un'esecuzione mostra ogni passaggio con la sua durata. Il passaggio dei test mostra i risultati dei test dell'autore.

Con Run workflow lo avvii a mano, per esempio subito dopo Synchronize now del mirror. Il pacchetto si trova in Artifacts, nella pagina dell'esecuzione.