Sinon il y a ce code d’expert qui fonctionne :
strJSON = '' + response.read().decode('utf-8')
data = json.loads(strJSON)
2 Likes
Bon la saga continue, merci beaucoup à @vit et @sveyret le problème de typage est enfin résolu, mais il y a encore un autre problème plus loin dans le script 
Le problème venait du fait que chez @florck qui utilisait l’objet comme une string, python le convertit en renvoyant la méthode repr de l’objet (une représentation), c’est automatique. hors dans l’image docker que j’utilise, cette conversion automatique ne se fait pas, ça doit être une version de python un pue plus stricte.
le code qui fonctionne :
response_data = response.read().decode()
data = json.loads(response_data)
Problème suivant :
$ python3 .gitlab/releaser.py
Traceback (most recent call last):
File ".gitlab/releaser.py", line 153, in <module>
main()
File ".gitlab/releaser.py", line 150, in main
compiled_message = build_compiled_message(current_message)
File ".gitlab/releaser.py", line 92, in build_compiled_message
'size': get_artifact_weight(artifact),
File ".gitlab/releaser.py", line 72, in get_artifact_weight
size = os.path.getsize(location)
File "/usr/lib/python3.5/genericpath.py", line 50, in getsize
return os.stat(filename).st_size
FileNotFoundError: [Errno 2] No such file or directory: 'duniter-desktop-0.99.19-linux-x64.deb'
ERROR: Job failed: exit code 1
je pense que le souci viens de la façon dont ce font les build, qui est différente de ce a quoi s’attendait le script de @florck a l’origine. En effet le script de build fourni un .zip , il faudrait donc soit :
- changer le script de build pour fournir 3 artifacts différents non zippés (je ne sais pas si ça viens de la config gitlab-ci ou du script de build de @sveyret ou un peu des deux)
- soit dézipper l’archive au sein du script python
je vais me pencher sur la 1ère option 
Je pense qu’il te manque une entrée dependencies dans le gitlab-ci.yml pour transmettre les fichiers créés par l’étape build. Je vais regarder.
1 Like
Non, à priori, ce n’est pas utile si les stage se suivent :
https://docs.gitlab.com/ce/ci/yaml/README.html#dependencies
Par contre, j’ai vu que tu avais mis un expires_in pour la partie deploy. Est-ce que c’est normal ?
Dans le gitlab_ci utiliser par @florck il n’y a pas d’entrée dependencies, en revanche il explicitait le chemin de chaque artifact : .gitlab-ci.yml · master · florck / demo-runner-perso · GitLab
j’ai donc fait pareil, le test est en cours : explain the path to each artifacts (ec96180a) · Commits · nodes / typescript / duniter · GitLab
Oui en fait on peut les keep manuellement si elles sont bonnes, mais ça ne sert a rien de laisser des pre-releases qui s’avérerait contenir un bug critique par exemple ou etre cassés
2 Likes
C’est une très bonne idée ces expires_in, d’ailleurs je peux attester que ça marche
2 Likes
Bon ça ne change rien au problème dans le test de @florck qui avait fonctionner les artifacts étaient a la racine hors la ils sont dans /work/bin/, croyez vous que çan puisse venir de là ?
l’erreur est toujours la même : enforce-message (#1389) · Jobs · nodes / typescript / duniter · GitLab
Est-ce que ce ne serait pas plutôt au niveau de EXPECTED_ARTIFACTS qu’il faudrait mettre le chemin complet ?
1 Like
@sveyret comme ça ? https://git.duniter.org/nodes/typescript/duniter/commit/a4b7333f8bd7d0ed861c153235c836e9360da10c
@sveyret ça change mais ce n’est toujours pas ça :
File ".gitlab/releaser.py", line 72, in get_artifact_weight
size = os.path.getsize(location)
File "/usr/lib/python3.5/genericpath.py", line 50, in getsize
return os.stat(filename).st_size
FileNotFoundError: [Errno 2] No such file or directory: 'https://git.duniter.org/nodes/typescript/duniter/repository/v0.99.23/archive.tar.gz'
ERROR: Job failed: exit code 1
@florck peut tu regarder ça de près vu que c’est ton script au départ car là ça fait une semaine qu’on ai dessus et même avec l’aide d’experts en python on s’en sort toujours pas…
J’essaie ce soir, sans garantie car j’ai énormément de boulot en ce moment.
1 Like
C’est pour le téléchargement des sources. Effectivement, cela veut dire que déjà, pour les binaires, c’est bon.
Ce qui est étrange, c’est que l’URL des sources est bonne. D’ailleurs, si on copie/colle l’adresse donnée, on télécharge bien le fichier. Je me demande si ce ne serait pas que os.path.getsize() n’accepte pas les URL, mais uniquement les fichiers locaux. Si c’est le cas, ça voudrait dire qu’il faudrait d’abord télécharger le fichier de sources avant d’exécuter ces instructions.
En tous cas, pour les tests, on peut peut-être temporairement commenter la partie qui gère les sources (de la ligne expected_sources… jusqu’à artifact_list.append….
Note aussi que dans expected_sources, contrairement à ce que je croyais au début, il ne faut pas mettre deb, mais ['tar.gz', 'zip'] puisqu’il s’agit des différents formats de fichiers (archive) sources à publier.
1 Like
@sveyret @florck @vit, le job a enfin réussi mais dans la tagpage générée les liens vers les paquets ne fonctionnent pas : https://git.duniter.org/nodes/typescript/duniter/tags
Si je clique sur « Download 'release_linux:deploy:desktop » alors je télécharger un fichier de 280Mo :
Et quand je l’extraie j’ai bien les 3 livrables (.deb server, .deb desktop, .tar.gz).
Oui mais ça c’était déjà le cas avant, si on s’est fait chi** pendant 1 semaine c’est pour avoir un résultat comme celui de @florck : test20 · Tags · florck / demo-runner-perso · GitLab
C’est a dire chaque paquet téléchargeable directement via un clic simple.
On ne peut pas demander a tout les utilisateurs de duniter de télécharger a chaque fois l’archive de tout les paquets alors qu’il n’en veulent qu’un seul 
Je veux bien faire des essais, je dois modifier la branche DockerBuild ou bien je peux m’en créer une autre ?
Putain de bordel de m**** ça maaaaarche ! https://git.duniter.org/nodes/typescript/duniter/tags/v0.99.26 !!!
Les url était cassés a case du nom du job qui n’étais pas le même partout, j’ai réglé ça 
Après 8 jours de galère nous avons enfin réussi, merci beaucoup à @sveyret et @vit pour votre très précieuse aide 
@sveyret comme tu le remarquera gitlab propose déjà le téléchargement des sources sous forme d’archive en cliquant sur l’icône de téléchargement en haut à droite donc on vas rester comme ça
Du coup, on vas pouvoir livrer la pré-release 1.6.15
4 Likes
@florck @cgeek il reste un dernier point d’ombre pour moi : Comment gitlab gère t’il la notion de pré-release vs release officielle ?
Sans vouloir dire d’ânerie, il me semble qu’il n’y a pas cette fonction dans GitLab.