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.
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]].
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
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
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 ?
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 :