pkgbuilds

Garuda Linux PKGBUILD

Ce référentiel contient des PKGBUILD pour tous les packages qui résident actuellement dans son référentiel garuda . Il fonctionne sur GitLab en raison de l'utilisation intensive de son CI et dispose d'un miroir GitHub en lecture seule.

Portée de ce dépôt

Tous nos propres PKGBUILD sont contenus ici. Historiquement, ceux-ci étaient divisés en leurs propres référentiels. Pour faciliter la recherche du bon PKGBUILD et permettre une contribution plus rapide, nous les avons récemment consolidés dans ce nouveau référentiel. Sont inclus les PKGBUILD de tous les packages, y compris leurs fichiers de configuration (cela s'applique aux fichiers plus petits comme garuda-fish-config ). Pour certains d'entre eux, comme les packages garuda-*-settings , le contenu peut toujours être trouvé dans leurs référentiels respectifs.

Vous avez trouvé un problème ?

Si des problèmes d'emballage ou des problèmes similaires surviennent, n'hésitez pas à les signaler via notre section problèmes. Vous pouvez cliquer ici pour en créer un nouveau.

Comment contribuer ?

Nous apprécions grandement les contributions de toute sorte ! ? Pour ce faire, veuillez suivre ces étapes :

• Créez un fork de ce référentiel.
• Clonez votre fork localement (court tutoriel git).
• Ajoutez les modifications souhaitées aux PKGBUILD ou au code source.
• Assurez-vous que shellcheck et shfmt ne signalent aucun problème avec les fichiers modifiés
  • Les dépendances nécessaires doivent être installées avant, par exemple. via sudo pacman -S shfmt shellcheck
  • Exécutez le script lint.sh via bash ./.ci/lint.sh vérifiez le code
  • Appliquer automatiquement certaines suggestions via bash ./ci/lint.sh apply
• Validez en utilisant un message de validation conventionnel et renvoyez toutes les modifications à votre fork.
  • L'application commitizen aide à créer un message de validation approprié. Vous pouvez l'installer via pip car il n'y a actuellement aucun package dans les dépôts Arch : pip install --user -U Commitizen . Ensuite, exécutez cz commit dans le dossier cloné.
• Créez une nouvelle demande de fusion dans notre référentiel principal.
• Vérifiez si l’une des exécutions du pipeline échoue et appliquez les éventuelles suggestions.

Nous examinerons ensuite les modifications et éventuellement les fusionnerons.

Gérer certains problèmes d'emballage

Paquets obsolètes et cassés

Il existe des cas de packages obsolètes, qui ne servent plus à rien et empêchent également les systèmes de se mettre à jour. Ceux-ci peuvent être gérés en ajoutant le package à conflicts() de garuda-common-settings et auto-pacman de garuda-update . Le résultat est que le package incriminé est automatiquement supprimé en raison du conflit.

Outils CI / build

Ce qui suit est partiellement extrait de la documentation des outils de construction, en omettant les informations non pertinentes pour ce dépôt. Si vous recherchez des instructions de configuration, veuillez plutôt utiliser le fichier README complet.

Général

Les déploiements peuvent être automatiquement déclenchés soit en modifiant le contenu dans un répertoire PKGBUILD, soit en ajoutant [deploy *] au message de validation. Contrairement aux vérifications PKGBUILD, celles-ci ne sont disponibles que pour les validations sur la branche main . Sont pris en charge :

• [deploy all] : Déploie une routine garuda complète, c'est-à-dire tous les PKGBUILD de ce référentiel.
• [deploy $pkgname] : Déploie le package pkgname , ce qui signifie qu'en le remplaçant par garuda-bash-settings , on déploierait garuda-bash-settings .

Une fois l’une de ces combinaisons détectée, le déploiement démarre après quelques vérifications réussies. Les journaux des déploiements passés peuvent être inspectés via la section Pipelines.

Bosses automatisées

Ce référentiel fournit un pipeline toutes les demi-heures qui met à jour tous les PKGBUILD vers leurs dernières versions si leur source réside dans un autre référentiel , en fonction de la dernière balise disponible. Il procède ensuite à la mise à jour des sommes de contrôle et renvoie les modifications à la branche principale. Un nouveau déploiement est automatiquement déclenché en ajoutant [deploy *] au message de validation. Cela signifie qu'il suffit de pousser une nouvelle balise pour déclencher le déploiement d'une nouvelle version de package pour ces packages. Remarque importante :

• Cela ne s'applique pas aux packages qui ont tous leurs fichiers dans ce référentiel
• Les balises ne doivent pas être préfixées par un v
• Les informations nécessaires sur la source d'un package sont fournies via le fichier SOURCES. Chaque ligne suit le schéma $url $pkgname $project_id . Ce dernier permet de récupérer la dernière balise via l'API GitLab et se trouve sur la page des paramètres généraux du référentiel.

Les dernières exécutions de ce travail peuvent être inspectées en parcourant la section pipelines, chaque pipeline avec le badge planifié a été exécuté par le minuteur. De plus, le pipeline peut être déclenché manuellement en parcourant la section des planifications de pipeline et en cliquant sur Exécuter la planification du pipeline .

Mise à jour manuelle des versions

Pour certains PKGBUILD, comme garuda-fish-config , tous les fichiers résident dans ce référentiel. Lors de la mise à jour des PKGBUILD, assurez-vous de mettre également à jour le fichier .SRCINFO correspondant car celui-ci est utilisé pour analyser toutes les informations relatives au package !

Ajout de packages

L'ajout de packages est aussi simple que de créer un nouveau dossier nommé d'après le $pkgbase du package. Mettez le PKGBUILD et tous les autres fichiers requis ici. Ajouter des packages AUR est donc aussi simple que de cloner son dépôt et de supprimer le dossier .git . CI s'appuie sur les fichiers .SRCINFO pour analyser la plupart des informations. Il est donc important de les avoir en place et à jour dans le cas de packages autogérés. Enfin, ajoutez un dossier .CI contenant la configuration de base ( CI_PKGBUILD_SOURCE est requis au cas où son package externe, les PKBUILD autogérés n'en ont pas besoin), validez toutes les modifications et repoussez les modifications vers la branche principale. Veuillez suivre la convention de validation conventionnelle ce faisant (cz-cli peut vous aider !). Cela signifie des commits comme :

• feat($pkgname): init
• fix($pkgname): fix xyz
• chore($pkgname): update PKGBUILD
• ci(config): update

Cela permet non seulement d’avoir un historique de validation uniforme, mais permet également la génération automatique d’un journal des modifications.

Supprimer des paquets

Cela peut être fait en supprimant le dossier contenant le PKGBUILD d'un package. Une tâche de nettoyage supprimera ensuite automatiquement tout package obsolète via l'exécution du pipeline on-commit . Cela prendra également en compte tous les packages fractionnés qu'un package pourrait produire. Renommer des dossiers compte également comme supprimer des packages.

Pipeline à la validation

Chaque fois qu'un nouveau commit est envoyé, le pipeline CI effectuera les actions suivantes :

• Vérification de la date de création de la dernière balise scheduled . Ceci est utilisé pour déterminer quels packages doivent être planifiés.
• Il analyse chaque validation pour une chaîne [deploy $foldername] , en acceptant uniquement les valeurs valides dérivées des dossiers PKGBUILD existants. [deploy all] est également un paramètre valide. Une faute d'orthographe $pkgname est une erreur fatale ici. Tous les problèmes doivent être résolus et poussés de force.
• Ensuite, les fichiers modifiés sont analysés. Cela inclut également les packages supprimés. Toute modification du contenu du dossier pertinent entraînera le déploiement du package correspondant.
• L'action finale consiste à créer les paramètres de planification (en les transmettant au travail planifié via des artefacts) et à supprimer tous les packages obsolètes au cas où une étape antérieure serait détectée.
• Si toutes ces actions réussissent, la balise scheduled est mise à jour afin que nous puissions nous y référer lors d'une exécution ultérieure du pipeline.

Pipeline dans les délais

Demi-heure

Toutes les demi-heures, le pipeline prévu effectuera quelques tâches :

• Mise à jour du modèle CI à partir du référentiel de modèles (au cas où cela serait activé via .ci/config )
• Vérifiez si la balise planifiée n'existe pas ou si planifiée ne pointe pas vers HEAD (dans ce cas, abandonnez la mission !)
• Vérifiez si l'arbre de travail .state contenant l'état des packages existe, si c'est le cas, il le configure. Sinon, il le recrée à partir de zéro (par exemple, en cas de poussée forcée)
• Vérifiez si le dernier commit est automatisé (contenant "chore(packages): update packages [skip ci]"), si oui, le commit résultant de la planification l'écrasera pour garder l'historique des commits propre.
• Collectez les horodatages AUR des packages pour déterminer si un PKGBUILD a changé
• Parcourez chaque package valide et effectuez les actions suivantes :
  • Lisez le fichier .CI/config pour obtenir des informations sur la configuration du package (par exemple, s'il faut gérer le référentiel AUR, la source du PKGBUILD, etc.)
  • Mettez à jour PKGBUILD dans les cas suivants :
    • CI_PKGBUILD_SOURCE est défini sur gitlab : met à jour le PKGBUILD à partir des balises du référentiel GitLab
    • CI_PKGBUILD_SOURCE est défini sur aur : met à jour le PKGBUILD à partir du référentiel AUR, en extrayant le dépôt git et en remplaçant les fichiers existants par les nouveaux. Si l’horodatage AUR n’a pas pu être collecté plus tôt, la mise à jour du package est ignorée.
    • CI_PKGBUILD_SOURCE n'est pas défini sur gitlab ou aur : tente de mettre à jour le PKGBUILD en extrayant le référentiel spécifié dans CI_PKGBUILD_SOURCE. Si le clonage échoue après 2 tentatives, le processus de mise à jour est ignoré.
  • Si CI_GIT_COMMIT est défini dans les variables de configuration des packages, le dernier commit de l'URL git défini dans la section source de PKGBUILD est mis à jour. Si cela diffère, planifiez une build.
  • Dans le cas où un hook personnalisé existe ( .CI/update.sh dans le répertoire du package), il est exécuté - cela peut être utilisé pour mettre à jour les PKGBUILD avec un script personnalisé.
  • Réécriture des variables nécessaires dans .CI/config (par exemple, hachage Git)
• Soit mettez à jour le PKGBUILD en silence en cas de modifications mineures, créez un PR pour examen en cas de mises à jour majeures (et seulement si CI_HUMAN_REVIEW est vrai)
  • Les mises à jour ne sont prises en compte que si diff signale réellement les modifications entre le dossier PKGBUILD actuel et le dépôt AUR PKGBUILD.
  • Toute modification apportée aux fichiers source est détectée, mais cela ne détecte pas les modifications malveillantes dans la source du projet en amont que le package construit
• L'arbre de travail d'état est mis à jour avec de nouvelles informations
• Les paramètres de planification sont construits et transmis à la tâche planifiée via un artefact
• Les branches obsolètes (par exemple, les PR d'évaluation fusionnés) sont supprimées
• La balise planifiée est à nouveau mise à jour

Tous les jours

Un calendrier de pipeline quotidien a été ajouté pour des packages spécifiques qui génèrent leur pkgver de manière dynamique. Pour l'utiliser, définissez CI_ON_TRIGGER=daily dans le fichier .CI/config du package.

Planification manuelle

Planification de packages sans commits git

Les packages peuvent être ajoutés manuellement à la planification en accédant à la page des exécutions du pipeline, en sélectionnant « Exécuter le pipeline » et en ajoutant PACKAGES en tant que variable avec les noms des packages comme valeur. Le pipeline récupérera ensuite les colis et les planifiera. PACKAGES peut également être défini sur all pour planifier tous les packages. Dans le cas où un ou plusieurs packages sont planifiés, ils doivent suivre le format pkgname1:pkgname2:pkgname3 .

Exécution de pipelines planifiés à la demande

Cela peut être fait en accédant à la page des exécutions du pipeline, en sélectionnant « Exécuter le pipeline » (le symbole de lecture). Un lien vers la page du pipeline sera fourni, où les journaux du pipeline pourront être obtenus.

Ajout d'interférence

Placez le fichier d'interférence requis dans le dossier .CI d'un dossier PKGBUILD :

• prepare : Un script qui est exécuté après la configuration du chroot de construction. Il peut être utilisé pour générer des variables d'environnement ou modifier d'autres éléments avant le début de la compilation.
  • Si quelque chose doit être configuré avant le processus de compilation proprement dit, les commandes peuvent être poussées en insérant par exemple. $CAUR_PUSH 'source /etc/profile' . De même, les conflits de packages peuvent être résolus, par exemple. comme suit : $CAUR_PUSH 'yes | pacman -S nftables' (les guillemets simples sont importants car nous voulons que les variables/pipes soient évaluées lors de l'exécution de l'invité et non en interférant)
• interfere.patch : un fichier de correctif qui peut être utilisé pour réparer soit plusieurs fichiers, soit PKGBUILD si de nombreuses modifications sont nécessaires. Toutes les modifications doivent être ajoutées à ce fichier.
• PKGBUILD.prepend : le contenu de ce fichier est ajouté au début de PKGBUILD.
• PKGBUILD.append : le contenu de ce fichier est ajouté à la fin de PKGBUILD. Corriger build() est aussi simple que d'ajouter le build() fixe dans ce fichier. Cela peut être utilisé pour toutes sortes de correctifs. Si quelque chose doit être ajouté à un tableau, c'est aussi simple que makedepend+=(somepackage) .
• on-failure.sh : Un script qui est exécuté si la construction échoue.
• on-success.sh : Un script qui est en cours d'exécution si la construction réussit.

Bumping pkgrel

Ceci est maintenant effectué en ajoutant la variable requise CI_PACKAGE_BUMP à .CI/config . Voir ci-dessous pour plus d'informations.

Arbres de dépendances

Le CI construit automatiquement des arbres de dépendances. Ils sont transmis au gestionnaire Chaotic en tant qu'artefact CI et lus chaque fois qu'une commande de planification est en cours d'exécution. Aucune intervention manuelle n'est nécessaire.

.CI/config

Le fichier .CI/config dans chaque répertoire de package contient des indicateurs supplémentaires pour contrôler les pipelines et créer des processus.

• CI_MANAGE_AUR : en définissant cette variable sur true , le CI mettra à jour le référentiel AUR correspondant à la fin de l'exécution d'un pipeline si des changements se produisent (en omettant les fichiers liés au CI)
• CI_PACKAGE_BUMP : contrôle les modifications de package pour tous les packages pour lesquels CI_MANAGE_AUR n'est pas défini sur true . Il augmente pkgrel de 0.1 pour chaque augmentation de +1 de cette variable.
• CI_PKGBUILD_SOURCE : définit la source de tous les fichiers liés à PKGBUILD, utilisée pour extraire les fichiers mis à jour à partir de référentiels distants. Les valeurs valides pour le moment sont :
  • gitlab : extrait le PKGBUILD des balises du référentiel GitLab. Il doit suivre le format gitlab:$PROJECT_ID . L'ID peut être obtenu en parcourant la section générale des paramètres du référentiel.
  • aur : extrait le PKGBUILD du référentiel AUR, extrait le dépôt git et remplace les fichiers existants par les nouveaux.
• CI_ON_TRIGGER : peut être fourni dans le cas où un déclencheur de planification spécial devrait planifier le package correspondant. Cela peut être utilisé pour planifier des packages quotidiennement, en définissant la valeur sur daily . Puisque cela vérifie si "$TRIGGER == $CI_ON_TRIGGER", toute planification personnalisée peut être créée à l'aide de planifications de pipeline et en définissant TRIGGER sur midnight , en ajoutant un calendrier d'ajustement et en définissant CI_ON_TRIGGER pour tout package concerné sur midnight .
• CI_REBUILD_TRIGGERS : ajoutez les packages connus pour provoquer des reconstructions à cette variable. Une liste de référentiels pour lesquels suivre les versions de package est fournie via le paramètre CI_LIB_DB des référentiels. Chaque version du package est hachée et sauvegardée dans .ci/lib.state . Chaque exécution de pipeline planifiée compare les versions en vérifiant les incompatibilités de hachage et déplacera chaque package concerné via CI_PACKAGE_BUMP .
• BUILDER_CACHE_SOURCES : peut être défini sur true au cas où les sources devraient être mises en cache entre les builds. Cela peut être utile en cas de sources lentes ou de sources qui ne sont pas disponibles à tout moment. Les sources seront automatiquement effacées après 1 mois, ce qui est important au cas où des packages seraient supprimés ou si la source changerait.

Gestion des packages AUR

Les packages AUR peuvent également être gérés via ce référentiel de manière automatisée à l'aide de .CI_CONFIG . Cela signifie qu'après chaque pipeline planifié et validé, le référentiel AUR sera mis à jour pour refléter les modifications apportées aux fichiers du dossier PKGBUILD. Les fichiers non pertinents pour la maintenance AUR (par exemple les dossiers .CI ) seront omis. Le message de validation reflète le fait que la validation a été créée par un pipeline CI et contient le lien vers l'historique de validation du référentiel source et l'exécution du pipeline qui a déclenché la validation de mise à jour.

Mise à jour des scripts du CI

Cela se fait automatiquement via le pipeline CI. Une fois les modifications détectées sur le référentiel de modèles, tous les fichiers seront mis à jour vers la version actuelle.

Problèmes et pannes de pipeline

Échec du dernier pipeline de validation

Cela peut se produire pour plusieurs raisons, par exemple après avoir fourni un nom de package invalide. Cela empêche la mise à jour de la balise scheduled . Dans ce cas, le pipeline prévu ne pourra pas s’exécuter. Le dernier pipeline validé doit être corrigé avant que le pipeline planifié puisse s'exécuter à nouveau. Les échecs de construction ne sont cependant pas pris en compte car la balise scheduled serait déjà mise à jour dès que les paramètres de planification seraient générés. Forcer la poussée d'un commit corrigé est activement encouragée dans un tel cas, car pousser un autre commit amènera le CI à évaluer les commits précédents qu'il a manqués, ce qui amènera à remarquer à nouveau le même problème et à renflouer au lieu de continuer silencieusement. Il s’agit d’une décision de conception visant à éviter que les pannes ne soient négligées.

Réinitialisation de la file d'attente de construction

Dans de rares cas, une réinitialisation de la file d'attente de construction peut être nécessaire. Cela peut être fait en arrêtant l'instance centrale Redis, en supprimant son dump et en redémarrant son service.

Gestionnaire chaotique

Cet outil est distribué sous forme de conteneurs Docker et se compose d'une paire d'instances de gestionnaire et de générateur.

• Gestionnaire : registry.gitlab.com/garuda-linux/tools/chaotic-manager/manager
• Constructeur : registry.gitlab.com/garuda-linux/tools/chaotic-manager/builder
  • Celui-ci contient la logique réelle derrière les constructions de packages (vues ici) connues depuis Infra 3.0 comme interfere.sh , database.sh etc.
  • Sélectionne les packages à créer à partir de l'instance Redis gérée par l'instance du gestionnaire

Le gestionnaire est utilisé par GitLab CI dans le travail schedule-package , planifiant les packages en l'ajoutant à la file d'attente de construction. Le constructeur peut être utilisé par n’importe quelle machine capable d’exécuter le conteneur. Il sélectionnera les tâches disponibles dans notre instance centrale Redis.

Configuration du développement

Ce référentiel contient un flocon NixOS, qui peut être utilisé pour configurer automatiquement les éléments nécessaires tels que les hooks et les vérifications de pré-validation, ainsi que les utilitaires nécessaires, via direnv. Cela inclut la vérification des PKGBUILD via shellcheck et shfmt . nix (le gestionnaire de paquets) et direnv sont nécessaires. Après cela, vous pouvez accéder à l'environnement en exécutant direnv allow .