Mettre en miroir le Git de l'auteur, lancer les tests, construire un QPKG : CI sur votre NAS

Forgejo, sur votre NAS, tient à jour un miroir du dépôt d'un programme. Un projet d'empaquetage distinct construit chaque jour la version la plus récente publiée par l'auteur, lance les tests de l'auteur et en fait un QPKG, sur le runner propre au NAS. L'exemple est fzy, un petit outil de recherche floue écrit en C (licence MIT).

1. ModulesGit, CI, l'Éditeur
2. Miroirle dépôt de l'auteur
3. ProjetNouveau projet, paquet QPKG
4. Workflowrécupérer, tester, construire
5. Exécutionsquotidiennes, sur un push, à la demande

Les images proviennent du panneau et de Forgejo de Bucket & Code Server IDE, avec chaque champ rempli comme le décrit ce guide. Le compte s'appelle ola.

01Avant de commencer

• Git, CI et l'Éditeur doivent être activés. Un module désactivé affiche un bouton sur sa tuile dans Vue d’ensemble et sur sa propre page : Activer Git, Activer Éditeur, et Activer Git et CI tant que Git est encore désactivé.
• QDK doit être installé : sur la page Toolchains, onglet QNAP, installez QNAP QDK 2.5.0.
• Il vous faut l'environnement de construction Ubuntu 24.04 : Apps → Exemples, ou Créer un environnement Builder sur la page Nouvelle app. Le workflow construit dans cet environnement.
• Le NAS doit avoir accès à Internet : actions/checkout et actions/upload-artifact viennent de data.forgejo.org, et le miroir récupère les changements depuis le serveur de l'auteur.

Le runner du NAS prend les tâches dont runs-on nomme l'un de ses labels, par exemple bucketvs. Il exécute chaque tâche sur le NAS lui-même, en tant qu'admin. Quiconque peut pousser un workflow dans un dépôt peut donc exécuter des commandes en tant qu'admin sur le NAS : n'accordez l'accès en push qu'aux personnes à qui vous confieriez le mot de passe admin du NAS.

02Mettre en miroir le dépôt de l'auteur

1. Dans Forgejo (Ouvrir Forgejo sur la page Git), appuyez sur + → Nouvelle migration → Git.
2. Collez l'adresse du dépôt de l'auteur, ici https://github.com/jhawthorn/fzy.git, cochez Ce dépôt sera un miroir, donnez-lui un nom, par exemple fzy-upstream, et appuyez sur Migrer le dépôt.
3. Le miroir récupère seul les commits et les tags de l'auteur. Ses Réglages affichent l'Intervalle de miroir (8 heures par défaut, 10 minutes au minimum) et Synchroniser maintenant.

Un miroir refuse les push : vous ne pouvez donc pas y ajouter votre propre workflow. Une synchronisation n'exécute que les workflows que le dépôt de l'auteur porte lui-même dans .forgejo/workflows/, et fzy n'en a aucun. La construction se fait donc dans un dépôt à vous, qui lit le miroir.

03Un projet d'empaquetage à vous

Ouvrez Nouveau projet depuis la page Git ou la palette de commandes (rôle développeur). Le guide Votre propre App Center détaille chaque étape ; pour cet exemple :

1. Modèle : Paquet QPKG.
2. Nom : fzy. Service : Outil en ligne de commande, qui crée un lien vers le programme dans /usr/bin tant que le paquet fonctionne.
3. Environnement de compilation : ubuntu2404-builder, l'environnement que le workflow utilise.
4. Appuyez sur Créer le projet. Le projet reçoit son dépôt, le dossier projects/fzy et le workflow du modèle, que la section 05 remplace.

Dans un dépôt créé avant l'activation de CI, les Actions de Forgejo sont désactivées, et un workflow poussé ne lance rien. Activez-les dans Réglages → Unités du dépôt ; les dépôts créés alors que CI est activé les ont déjà.

04Un jeton en lecture seule pour le miroir

Le job clone le miroir en HTTPS. Sauf si le miroir est public et que Navigation publique est activé, ce clone demande une connexion, et le workflow lui donne un jeton qui ne peut que lire.

1. Dans Forgejo, Réglages → Applications → Generate new token : un nom tel que mirror-read, la permission dépôt : Read. Copiez le jeton : Forgejo ne l'affiche qu'une fois.
2. Dans le dépôt de packaging, Réglages → Actions → Secrets → Add secret : le nom MIRROR_TOKEN et le jeton comme valeur.

05Le workflow

Placez ce fichier dans le projet sous le nom .forgejo/workflows/build.yml, à la place de celui du modèle, puis poussez-le. Il s'exécute à chaque push, une fois par jour et à la main.

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

• La deuxième étape prend le tag le plus récent du miroir, pour que le paquet suive les versions de l'auteur, et sa version devient celle du paquet (QPKG_VER).
• bvs env run ubuntu2404-builder -- … compile et teste dans l'environnement, avec son compilateur et ses bibliothèques. Un test en échec fait échouer l'exécution, et rien n'est empaqueté.
• bvs qbuild construit le paquet dans build/. L'exécution le conserve comme artefact.
• La dernière étape publie dans le dépôt App Center du NAS, qui n'accepte que les paquets signés. Sans certificat, l'exécution se termine par un avertissement et le paquet reste un artefact. Le guide Votre propre App Center présente les deux étapes qui signent chaque build.

06Exécutions, tests et paquet

L'onglet Actions du dépôt liste chaque exécution avec ce qui l'a lancée : un push, la planification ou une personne.

Une exécution affiche chaque étape avec sa durée. L'étape des tests affiche les résultats des tests de l'auteur.

Run workflow la lance à la main, par exemple juste après Synchronize now du miroir. Le paquet se trouve sous Artifacts, sur la page de l'exécution.