CI (continuous integration) application GitLab Runner pour YunoHost

Bonjour à tous et toutes,

Après avoir lu cet échange : Mise en place de CI (continuous integration), j’ai regardé dans la bibliothèque d’applications de YunoHost, une application GitLab Runner existe.

https://apps.yunohost.org/app/gitlab-runner


Question d’actualité : y a-t-il besoin de GitLab Runner supplémentaires depuis janvier 2025 ?

bonjour,

oui des runners supplémentaires sont toujours utiles : cela réparti la charge, peut accélerer parfois lorsqu’il y a beaucoup de taches en cours et en plus il y a une volonté de certain·es d’étendre les tests aux plugins.

Ok, je peux fournir une instance. À l’installation, l’application demande trois configurations :

  1. Veuillez entrer l’URL du coordinateur GitLab-CI : https://git.spip.net
  2. Veuillez entrer le jeton GitLab-CI pour ce Runner :
  3. Veuillez entrer l’image du Docker : alpine:latest (proposé par defaut)
  1. Veuillez entrer le jeton GitLab-CI pour ce Runner :

Le jeton est fourni par un admin de git ? (Si j’ai bien lu).

1 « J'aime »

oui. je t’envoi un mp

Merci, jeton bien reçu :pray:
Si je propose une autre instance de Gitlab Runner, un jeton différent doit être utilisé ?

oui

Le GitLab Runner est installé et semble fonctionner, l’installateur de YunoHost renvoi ces infos à l’admin :

Comment configurer cette application: via le panneau d’administration de GitLab ou les paramettres « CI/CD » de votre projet.

Configuration système

Lors du premier démarrage d’un Gitlab Runner, un exécuteur doit être choisi (Lorsque l’instance Gitlab Runner s’enregistre auprès d’une instance Gitlab). Pour l’instant, cette application YunoHost ne supporte que l’exécuteur docker.

Informations additionnelles

  • Pour récupérer les informations à fournir à l’installation comme le token ou l'url gitlab vous devez vous rendre ici : Settings->CI/CD->Runners->"Set up a specific Runner manually" dans le projet
    ou la section admin de l’instance GitLab à relier à ce runner.
  • Si vous avez ce message pendant un travail : Could not resolve host : you.domain.tld, vous pouvez ajouter dns_search = ["you.domain.tld"] dans la section [[runners]].

oui, donc tout est bon.

Merci pour ça @Plumf ! Et si d’autres personnes peuvent fournir des runners, ça sera bénéfique pour toute la communauté :slight_smile:

Tu peux jouer sur ta config avec les « concurrent » pour en mettre plus si ton serveur est puissant et dispo.

Pense à le maintenir à jour aussi

L’avantage et la contrainte avec YunoHost, c’est que ça facilite mais peut limiter l’installation ou la configuration (sans mettre les mains dans le cambouis j’entend). Du fait, avec YnH pas vu passer cette notion de « concurrent » .

Autre inconvénient, les mises à jour dépendent de la maintenance du paquet YnH permettant le déploiement de l’application. le paquet est en version 18.6.2 alors que la dernière version publié est 19.2.0

Celui fourni hier est hébergé sur un VPS OVH. Je peux en proposer un supplémentaire, mais auto-hébergé (connexion fibre). Intéressé ?

@Plumf ton runner à un soucis :

      Running on runner-rca7wihq-project-1679-concurrent-0 via bruce.epider.me...
Getting source from Git repository
Gitaly correlation ID: 01KYVKP32TG0DJ6TN4YZSX8F97
Fetching changes with git depth set to 20...
Reinitialized existing Git repository in /builds/spip-league/hasher/.git/
Created fresh repository.
fatal: unable to access 'https://git.spip.net/spip-league/hasher.git/': Could not resolve host: git.spip.net
Retrying in 5s
Cleaning up project directory and file based variables
ERROR: Job failed: exit code 1

Visible ici aussi job:build (#14818) · Jobs · spip / ecrire · GitLab

Et une autre erreur sur un autre Job

WARNING: Failed to pull image with policy "always": Error response from daemon: failed to resolve reference "docker.io/library/php:latest": failed to authorize: failed to fetch anonymous token: Get "https://auth.docker.io/token?scope=repository%3Alibrary%2Fphp%3Apull&service=registry.docker.io": dial tcp: lookup auth.docker.io on 127.0.0.1:53: read udp 127.0.0.1:42700->127.0.0.1:53: i/o timeout (manager.go:237:10s)

Là c’est possible que ça tombe sur des limites de l’api docker.io

@marcimat @pierretux, je veux bien enqueter au niveau de mon serveur et/ou faire des modifications, mais je vais avoir besoin d’aide. Je vais aussi poser la question sur le forum de YunoHost, voir s’il y a des pistes de côté.

@pierretux dans la documentation admin de l’app YnH, il est indiqué :

Si vous avez ce message pendant un travail : Could not resolve host : you.domain.tld, vous pouvez ajouter dns_search = ["you.domain.tld"] dans la section [[runners]].

ça semble correspondre au problème dans le job que tu as pointé. Ça se passe côté git.spip.net ou du côté de mon GitLab Runner ?

Probablement dans ton /etc/gitlab-runner/config.toml

1 « J'aime »

J’ai appliqué la correction suggérée :
C’est bien ici :

A surveiller…

Dans les logs (hastebin), il y a une serie d’erreurs affiché et surtout il y a cette avertissement :

WARNING: CONFIGURATION: Long polling issues detected.
Jul 31 18:19:17 gitlab-runner[4202]: Issues found:
Jul 31 18:19:17 gitlab-runner[4202]:   - Request bottleneck: 1 runners have request_concurrency=1, causing job delays during long polling
Jul 31 18:19:17 gitlab-runner[4202]: This can cause job delays matching your GitLab instance's long polling timeout.
Jul 31 18:19:17 gitlab-runner[4202]: Recommended solutions:
Jul 31 18:19:17 gitlab-runner[4202]:   1. Increase 'request_concurrency' to 2-4 for 1 runners currently using request_concurrency=1
Jul 31 18:19:17 gitlab-runner[4202]: Note: The 'FF_USE_ADAPTIVE_REQUEST_CONCURRENCY' feature flag can help automatically adjust request_concurrency based on workload.
Jul 31 18:19:17 gitlab-runner[4202]: This message will be printed each time the configuration is reloaded if the issues persist.
Jul 31 18:19:17 gitlab-runner[4202]: See documentation: https://docs.gitlab.com/runner/configuration/advanced-configuration.html#long-polling-issues  builds=0 max_builds=1
Jul 31 18:20:05 gitlab-runner[4202]: Usage logger disabled                               builds=0 max_builds=1
Jul 31 18:20:05 gitlab-runner[4202]: Configuration loaded                                builds=0 max_builds=1

Le fichier de conf /etc/gitlab-runner/config.toml :

concurrent = 1
check_interval = 0
connection_max_age = "15m0s"
shutdown_timeout = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = "bruce.epider.me"
  url = "https://git.spip.net/"
  id = 23
  token = "xxxxxxxxxxxxxxx"
  token_obtained_at = 2026-07-26T14:00:10Z
  token_expires_at = 0001-01-01T00:00:00Z
  executor = "docker"
  dns_search = ["git.spip.net"] #Fix https://discuter.spip.net/t/ci-continuous-integration-application-gitlab-runner-pour-yunohost/201553/13
  request_concurrency = 3  #Fix Gitlabrunner warning log https://paste.yunohost.org/exiwufucis
  [runners.cache]
    MaxUploadedArchiveSize = 0
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]
  [runners.docker]
    tls_verify = false
    image = "alpine:latest"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
    network_mtu = 0

Concernant request_concurrency = 3 je l’ai mis à 3 mais le retour de GitlabRunner annonce 2-4 (j’ai choisis le médian), un avis ?


Après redémarrage, l’avertissement ne s’affiche plus. Y a-t-il d’autres pistes ?

Je vais réactiver ton runner, on verra s’il y a des améliorations.