J'ai récemment voulu faire passer un exécuteur Gitlab que j'avais configuré pour mon instance Gitlab auto-hébergée du statut de gestionnaire de projet (c'est-à-dire d'exécuter des tâches uniquement pour un projet) à celui de gestionnaire de groupe (afin qu'il puisse également exécuter des tâches pour autres projets du même groupe). Je voulais conserver les paramètres /etc/gitlab-runner/config.toml que j'avais minutieusement écrits à la main.
Heureusement, j'ai sauvegardé config.toml , car sudo gitlab-runner unregister -t ... -u ... a supprimé toute la configuration de config.toml.
Afin d'obtenir le même config enregistrée sous le groupe au lieu du projet, je devais:
sudo gitlab-runner register \ --non-interactive \ --url <URL HERE> --registration-token <TOKEN HERE> \ --executor docker \ --docker-image docker:dind \ --paused
Accédez au nouveau config.toml que cela a créé et copiez le jeton de coureur individuel du coureur.
Remplacez config.toml par la configuration souhaitée.
Modifiez le config.toml et insérez le nouveau jeton de coureur individuel.
Démarrez le service Gitlab runner ( sudo systemctl start gitlab-runner ).
Réactivez le runner dans l'interface utilisateur Web de Gitlab.
Même après avoir fait tout cela, l'instance Gitlab voit toujours le coureur sous le nom avec lequel il s'est enregistré dans la configuration factice, plutôt que le nom dans le config.toml . p>
Essayer l'option --config sur gitlab-runner register ne fonctionnait pas du tout; Je pense que cela lui indique simplement où enregistrer la configuration. Cela m'a quand même demandé de nouveaux paramètres à utiliser au lieu de lire depuis le config.toml sur lequel je l'ai indiqué.
La documentation de Gitlab sur l'enregistrement des coureurs est entièrement rédigée en un seul coup > commandes gitlab-runner register avec des tas d'options qui spécifient essentiellement la configuration entière sur la ligne de commande. Je ne veux vraiment pas traduire manuellement mon config.toml en une ligne de commande qui se retourne et le reconstruit (sans aucun commentaire, bien sûr).
Je ne peux pas pense que c'est vraiment le bon workflow pour réenregistrer un runner avec une nouvelle instance de projet / groupe / Gitlab, ou pour créer une copie d'un runner à partir d'une configuration enregistrée. Qu'est-ce que j'oublie ici? Comment puis-je créer un nouveau runner Gitlab à partir d'un fichier config.toml existant?
3 Réponses :
Il n'y a pas de moyen facile de faire ce que vous voulez, d'après ce que je peux trouver dans la documentation de GitLab et certains problèmes en suspens qu'ils ont.
Voici un problème qui décrit quelque chose de similaire à ce que vous voulez:
https://gitlab.com/gitlab-org/ gitlab-runner / issues / 3540
Voici ce que je pense être l'objectif de GitLab en ce qui concerne l'inscription des coureurs:
https://gitlab.com/gitlab-org/gitlab-ce/issues/40693
Je crois que la seule chose que vous ne pouvez pas changer à partir du fichier .toml est le nom du coureur, et peut-être pas les balises non plus. Ensuite, le nom n'est créé que lorsque vous enregistrez le coureur. J'ai lu quelque chose que vous pouvez modifier les balises d'un coureur partagé, mais je ne le trouve pas maintenant.
Voici une solution de contournement pour rendre le processus d'enregistrement un peu plus automatique:
https://gitlab.com/gitlab-org/gitlab -runner / issues / 3553 # note_108527430
Il a utilisé cette API:
{"id":401513,"token":"<runner-token>"}
Ensuite, il a obtenu la réponse suivante: p >
curl --request POST "https://gitlab.com/api/v4/runners" --form "token=<registration-token>" --form "description=test-1-20150125-test" --form "tag_list=ruby,mysql,tag1,tag2"
Il pourrait alors injecter le jeton de runner dans son fichier .toml déjà pré-fait.
Pour vous, il aurait été possible d'utiliser le jeton d'enregistrement pour votre groupe, puis d'écrire dans la description / le nom du coureur et les balises. Vous pourriez alors avoir réutilisé votre config.toml et seulement changé le jeton de runner, et cela aurait dû fonctionner.
Nous stockons les configurations de runner dans un référentiel pour la restauration.
Pour restaurer un coureur, nous:
gitlab-runner (voir https: //docs.gitlab .com / runner / install / ) sur le nouveau nœud, /etc/gitlab-runner/config.toml et redémarrage du service sudo gitlab-runner sur ubuntu. Jusqu'à présent, cette procédure était très fiable.
Pour créer les coureurs au départ, vous devez toujours les enregistrer via gitlab-runner register , non? Ce serait juste utile pour restaurer les coureurs déjà inscrits, n'est-ce pas?
Un runner gitlab peut être enregistré avec plusieurs projets et / ou groupes. Cela ajoutera simplement les configurations dans /etc/gitlab-runner/config.toml (avec sudo). Pouvons-nous simplement faire les étapes suivantes:
config.toml stocke toute la configuration qui est passée au gitlab-runner register , y compris toutes les variables d'environnement répertoriées sous gitlab-runner register -h < Commande / code>.
Je ne sais pas pourquoi vous devez enregistrer le config.toml .
De plus, je pense qu'une source de confusion pourrait être gitlab-runner-token VS gitlab-runner-registration-token . Le registration-token ne peut PAS être utilisé dans config.toml , ce qui peut être la raison pour laquelle vous avez échoué après un simple remplacement. Si vous ne souhaitez pas utiliser la commande gitlab-runner register et simplement mettre à jour le config.toml , suivez les étapes définies dans les ans ci-dessus pour récupérer le gitlab- runner-token et utilisez-le dans config.toml . Nous pouvons alors essayer d'arrêter et démarrer le service gitlab-runner en utilisant sudo service gitlab-runner stop et sudo service gitlab-runner start