Je cherche à faire fonctionner les builds de Cesium par la CI gitlab.
Du coup, je vois que je n’ai pas dans le projet l’accès au docker registry.
Quelqu’un sait il comment l’activer sur le projet ? Je crois qu’il faut que ce soit un administrateur qui le fasse…
merci !
Ah bah non ca à l’air déjà activé :
Je dois avoir un autre problème dans mon CI…
EDIT : je vois que le build de Duniter n’utilise plus le docker registry de gitlab :
#- docker login -u "gitlab-ci-token" -p "$CI_BUILD_TOKEN" $CI_REGISTRY
#- docker push "$CI_REGISTRY_IMAGE:$IMAGE_TAG"
# Temporary push on dockerhub
- docker login -u "duniterteam" -p "$DUNITERTEAM_PASSWD"
Savez vous la raison de cela ?
Je ne comprends pas, dans j’essai de pusher mon image docker;, j’ai cette erreur :
$ docker push ${CONTAINER_BUILD_IMAGE}
The push refers to repository [registry.duniter.org/clients/cesium-grp/cesium]
9b2eecfe1dca: Preparing
(...)
3125b578849a: Waiting
denied: requested access to the resource is denied
Bon, ca avance… ma ligne doker login (...) avait sauté, à cause de l’héritage.
Au passage @moul j’ai regardé ta merge request pour utiliser èxtends pour la CI de duniter, et ca me parait bien 
Qui d’autre peut regarder ? @cgeek ?
Mon build va un peu plus loin, mais plante avec 500 Internal Server Error
d7aef11e5baf: Retrying in 2 seconds
d7aef11e5baf: Retrying in 1 second
14ce51dbae6e: Pushed
50c78a431907: Pushed
3125b578849a: Pushed
e4912e4347af: Pushed
received unexpected HTTP status: 500 Internal Server Error
Peut-etre un problème de place ?
Tu peux approuver la MR. Ça me semble ok pour fusionner ainsi. Je sais pas si ça convient à Éloïs.
Super que tu t’occupes de remettre sur pied la CI/CD pour Césium !
Rah, c’est le problème que j’ai passé sous silence. J’ai ce problème depuis un moment que je rencontre pour pusher mes images sur le registry. Ça me bloque pour pusher l’image qui devrait contenir DeathReaper ainsi que pour mettre à jour les images Python pour faire tourner les pipelines de Silkaj et DuniterPy.
Je ne sais pas comment ce problème n’est pas rencontré avec la CI de Duniter. Il est surement contourné par ce commit (pour quelle raison as-tu fait ce commit @elois ?) et c’est pas testé et cassé pour la génération de l’image de production.
J’ai beaucoup cherché et essayé de solutions dans les tickets trouvés sur la forge de développement de GitLab. En gros, les layers de l’image n’arrivent pas à être pushé à un certain moment.
Je ne pense pas.
Ok, je suis donc pas le seul à avoir ce soucis. C n’est donc pas un pb de ma config.
Sais tu où l’on peut trouver les log du container registry ? Est-ce qu’il y aurait dedans un message plus clair, derrière l’erreur 500 ?
Vu passé le mail sur cette MR il y a 3 jours mais j’ai pas le temps pour Duniter en ce moment, j’ai d’autres impératifs à très court terme.
Je viens de reviewer cette MR, tout est on pour moi c’est mergé 
Pour les mêmes raisons que toi et benoit, j’avais fait remonter cette impossibilité de pusher de nouvelles images sur notre registry il y a déjà plusieurs mois, ne sachant pas comment régler le problème je contourne en passant par dockhub, ce qui marche très bien.
En regardant les logs (merci pour la piste), j’ai pu identifier une piste : les droits n’étaient pas bons. Il y avait des git:git à certains endroits, plus bas dans l’arborescence par rapport à ce qui était décrit dans le ticket. Je ne sais pas si c’est lié à des restaurations de sauvegardes, je ne sais plus si on en a fait lors des spams. J’ai relancé les deux jobs d’upload d’images Césium et Silkaj sur le registry et c’est passé !
Du coup, le build sur /develop fonctionne nickel.
J’aimerai utiliser gitflow pour faire mes releases.
Savez-vous si le processus peut être lancé depuis un CI ?
J’ai une erreur qui me dit que la branche est détachée. Du coup je me demande si gitlab ne gère pas des branches détachées pour chaque tâche, ce qui empêche gitflow de fonctionner.
Vous faites comment vous avec gitflow ??
Autre question, une fois que les artefacts sont construits, pour une release, comment peut on les publier dans une page (par exemple avec un tableau avec les différentes version).
Sur Duniter j’ai l’impression que c’est fait via des scripts node. Ou alors j’ai rien compris 
PS : un ne solution que j’ai trouvé, pour lancer la release depuks le CI, est de refaire un git clone dans ma tâche. Mais c’est pas très propre, je trouve…
On utilise pas gitflow
C’est géré par des scripts python écrit par @sveyret , ils sont dans le dossier .gitlab
ok. Du coup, comment lances tu une release ? via le CI (tache manuelle) ou autrement depuis ton poste ?
Je vais proposer une MR pour rebasculer duniter sur le container registry de notre gitlab.
Je vais notamment ajouté une tache .docker: qui fait le login à notre container registry
Oui exactement
J’ai besoin qu’on push aussi sur le dockerhub, d’autres truc en dépendent. Donc plutot rajouter un push sur notre registry mais pas remplacer stp