ok on vas donc devoir modifier manuellement le dépot website a chaque nouvelle version officielle, en même temps c’est qqch a faire très rarement donc ce n’est pas choquant outre mesure 
Oui, de toute façon ça permet d’éviter de propager une version qui serait une erreur par exemple. En plus, modifier la version sur le site ça prend littéralement 10 secondes : modification du fichier, commit et push. Terminé.
Ce ne serait pas la notion d’environnement qui pourrait nous aider par hasard ?
Il y a même la notion de rollback…
J’ai l’impression que la config de @florck ne gère pas les environnements (stages) comme on le voudrait.
En fait, en lisant en diagonale la doc, on peut avoir des déploiements en production si on le configure via un merge sur une branche. On doit pouvoir faire pareil pour les prérelease avec la branche « dev » par exemple.
A creuser…
1 Like
Je trouve que ce “work/bin/” est un peu moche alors je tente de modifier le script python pour le faire disparaitre du nom affiché : releases page : try to hide path in release name (ab0fa2f8) · Commits · nodes / typescript / duniter · GitLab
je découvre python alors si je fais peut être de la merde mùais c’est en essayant qu’on apprend 
EDIT:
Perso j’ai eu ma dose pour le moment, mais si quelqu’un veut tenter d’intégrer cette notion d’environnement sur une nouvelle branche, faîtes vous plaisir 
Bon ça marche maintenant, en plus je vois qu’on peut aisément ajouter manuellement d’autres binaires : v0.99.27 · Tags · nodes / typescript / duniter · GitLab
EDIT : j’ai restaurer les jobs de build et de test, je laisse tourner la pipeline classique et si tout passe bien je merge enfin la MR de @sveyret
EDIT2 : c’est mergé !
1 Like
3 Likes
J’ai hâte de tester tout cela, je vais avoir du temps ce week-end ça tombe bien 
1 Like
@sveyret : Tu saurais m’expliquer le principe du script de bootstrap ? https://git.duniter.org/docker/duniter/release-builder/blob/master/bootstrap.sh
J’y connais pas grand chose à docker, mais là je vois un script “entrypoint” qui n’a pas l’air de faire grand chose… du coup je suis perplexe
Son rôle est principalement de modifier le propriétaire des fichiers du projet.
L’objectif est de ne pas compiler en tant que root, donc on a un utilisateur duniter à l’intérieur de l’image Docker. Mais cet utilisateur n’est pas connu à l’extérieur de l’image. Le script se charge donc, en tant que root, de modifier le propriétaire des fichiers avant d’exécuter les commandes en tant que duniter, puis re-modifier le propriétaire dans l’autre sens lorsque le traitement est terminé.
A quel moment est-ce que le terminate est joué ? Là, en le lisant comme ça, j’aurais plutôt l’impression qu’il se joue dès le début du run docker… Je dois mal comprendre quelque chose.
La partie :
su - duniter
lance un shell au nom de duniter. Le shell ne s’arrête que lorsqu’il reçoit la commande exit. C’est à ce moment-là que le terminate s’exécute.
1 Like