Nouveau en 0.4.22
Configurer la CI d’un dépôt
Ouvrez CI/CD dans la barre de navigation. Cette version configure l’intégration continue ; elle ne déploie pas votre application.
Les noms des commandes ci-dessous correspondent à l’interface en anglais.
Avant de commencer
Un abonnement payant et un dépôt avec des commits
Connectez-vous sous Account avec un abonnement payant ; une place dans une équipe payante Team, Business ou Enterprise compte, mais pas un essai. La configuration nécessite un serveur Termiyo accessible avec les modèles CI de la version 0.4.22. Envoyez un premier commit dans le dépôt avant de configurer la CI.
11 types de projets
Build it as propose Node.js, Python, Go, Rust, Java (Maven), Java (Gradle), Ruby, PHP, .NET, Docker image et A blank starting point. La détection GitHub et GitLab lit les noms des fichiers à la racine du dépôt ; vérifiez le choix et sélectionnez un type si plusieurs correspondent. Le modèle vierge contient une étape provisoire à remplacer.
GitHub
1. Préparer un jeton
Choisissez GitHub et appuyez sur Open GitHub’s token page. Utilisez un jeton d’accès personnel à permissions fines limité au dépôt : Contents, Workflows et Pull requests nécessitent Read and write ; Actions et Metadata nécessitent Read. Fixez une expiration à 90 jours ou moins. Seul github.com est pris en charge, via api.github.com ; GitHub Enterprise ne l’est pas.
2. Enregistrer et vérifier
Choisissez Saved token ou appuyez sur Save a new token, remplissez Name et Paste the token, puis appuyez sur Save to key box. Dans Repository, saisissez owner/name ou son lien github.com et appuyez sur Check. Vous pouvez aussi utiliser List repositories this token can see.
3. Vérifier le fichier et ouvrir la pull request
Choisissez Build it as, appuyez sur Show the file, examinez le fichier, puis appuyez sur Set up CI. Termiyo crée un commit de .github/workflows/termiyo-ci.yml sur termiyo/ci-setup et ouvre une pull request. Utilisez Open in browser pour l’examiner et la fusionner. La CI peut s’exécuter sur la pull request ; la branche par défaut reste inchangée jusqu’à la fusion.
GitLab
1. Indiquer le projet et préparer un jeton
Choisissez GitLab. Dans Project, saisissez group/project pour gitlab.com ou l’URL HTTPS complète du projet sur votre propre GitLab, puis appuyez sur Open GitLab’s token page. Utilisez un jeton d’accès personnel ou de projet avec la portée api ; elle autorise tout ce que son propriétaire peut faire. Choisissez donc une durée courte et révoquez le jeton après la configuration.
2. Vérifier le projet et les exécuteurs
Choisissez Saved token ou utilisez Save a new token → Save to key box, puis appuyez sur Check. Choisissez Build it as. Si aucun exécuteur n’est disponible, activez les exécuteurs partagés ou enregistrez-en un pour le projet avant de fusionner ; le panneau indique aussi lorsque le jeton ne permet pas d’établir leur disponibilité.
3. Vérifier le fichier et ouvrir la merge request
Appuyez sur Show the file, examinez le fichier et appuyez sur Set up CI. Termiyo crée un commit de .gitlab-ci.yml sur termiyo/ci-setup et ouvre une merge request. Utilisez Open in browser pour l’examiner et la fusionner ; la branche par défaut reste inchangée jusqu’à la fusion.
Giti : Repos on a host
1. Vérifier l’hôte
Connectez-vous à l’hôte SSH qui contient votre dépôt Giti et choisissez Repos on a host. Cet exécuteur nécessite Linux sur x86_64 ou ARM64, git et Docker utilisable par le compte SSH, ainsi que curl ou wget, tar, sha256sum ou shasum et timeout. Termiyo n’installe pas Docker ; demandez à l’administrateur de l’hôte ou utilisez Docker sans root.
2. Installer et activer
Appuyez sur Install the CI runner. Termiyo télécharge nektos/act 0.2.89 dans ~/.termiyo/bin et vérifie son SHA-256 avant toute extraction ou exécution. Pour le dépôt, choisissez Build it as et appuyez sur Turn CI on. Un hook post-receive existant provenant d’un autre outil reste intact et empêche la configuration automatique.
3. Fusionner, envoyer et lire le résultat
Si Termiyo a créé la branche de workflow termiyo/ci, utilisez Copy pour copier les commandes affichées et exécutez-les dans votre clone sur la branche par défaut afin de fusionner et d’envoyer les changements. L’hôte exécute alors .github/workflows/termiyo-ci.yml avec act dans Docker après les pushes du propriétaire ; ceux des collègues autorisés ne lancent jamais la CI. Utilisez Refresh et Log pour lire les résultats, et Turn CI off pour désactiver le hook.
Ressources sur votre hôte
Chaque exécution est limitée à 30 minutes. Termiyo demande à Docker le réseau bridge, aucun socket Docker dans le job, aucun nouveau privilège et des limites de 2 CPU, 4 Go de mémoire et 512 processus ; leur application dépend du Docker de l’hôte. La première exécution télécharge une image de 2,3 Go.
Limites et vérification
Workflows existants et abonnements
Pour GitHub et GitLab, Termiyo n’écrase jamais le fichier de workflow cible ; si .gitlab-ci.yml existe, il propose un modèle à intégrer manuellement. L’abonnement payant couvre la configuration depuis Termiyo : la lecture des exécutions n’est pas soumise à l’abonnement et la CI déjà configurée continue de fonctionner après son expiration. Les modèles proviennent du serveur Termiyo et doivent correspondre aux empreintes fixées dans l’application.
Vérifications effectuées
La configuration GitHub et GitLab a été testée avec des simulations, pas avec de vrais comptes. Giti CI a terminé une exécution réelle sur un hôte x86_64. Le déploiement n’est pas implémenté dans cette version.