Publication automatique des releases Duniter

[troll on]
C’est marrant d’utiliser une image tensorflow… je savais pas qu’on utilisait des réseaux de neurones dans duniter ! :smiley:
[troll off]

Oui, j’ai corrigé le truc.
Mais, je me suis posé des questions.
Qu’est-ce que c’est que cette image.
C’est quand même un bazooka pour tuer un moustique.

Faudrait voir si y’a une image avec python et jinja2 dessus devrait suffire.

Tout ça pour faire tourner du Python.

4 Likes

Faut demander a @sveyret :open_mouth:

Ça ne me dit rien du tout. Je pense que j’ai utilisé l’une des images déjà disponibles sur le CI à l’époque.

1 Like

Et la conversation.

Arf j’avais oublié ça remonte a plus d’1 an :sweat_smile:

Face au problème, voulans avancer j’avais du chercher “python” dasn docker hub et j’ai pris la 1ère image qui fonctionnait. Je ne savais pas que tensorflow désignais un truc sur l’IA, l’IA n’est pas mon domaine et le python encore moins.

Ok, voici une image minimaliste d’Alpine avec Python 3.6 et jinja2.

La pipeline avec les jobs prerelease et release qui ont réussit pour cette image.

Les sources de l’image et sur DockerHub.

4 Likes

Bien, par contre ce serait cool de nettoyer un peu le wiki à la main car c’est un peu le bazard, il y des versions temporaires ou des versions obsolètes en tête de liste (1.7.11 par exemple).

Aussi, le job “prerelease” pourrait n’être réservé qu’à un motif particulier de tag, par exemple respectant la regexp /v[1-9]\.[0-9]{1,2}\.[0-9]{1,2}/ (“v” puis 1 chiffre de 1 à 9, un point, puis max 2 chiffres, un point, et enfin deux chiffres max).

Ainsi le comportement serait :

  • v1.7.16 ==> OK pour construction des livrables + éditer la page des prereleases
  • 2019.0407.1406 ==> KO, construire uniquement les livrables
  • v2019.0409.2035 ==> KO, construire uniquement les livrables

Je crois qu’en GitLab CI ça se fait assez bien.

Je pense qu’il faut fouiller par là, mais je n’ai pas trouvé de mécanisme regex sur les tags.

Ici : https://stackoverflow.com/a/44923477

1 Like

Les liens du wiki sont brisés… Impossible de télécharger la dernière release 1.7.16.

J’ai reconstruit les paquets.
Je m’occupe de corriger la source du problème asap.
J’ai mis à jour les liens manuellement dans les parties Wiki, tags et releases.

2 Likes

Ok, les artefacts des releases stables expiraient au bout de deux semaines.
C’est corrigé !

On a deux semaines pour sortir une 1.7.17 :slight_smile:


Et en promo, un fichier de CHANGELOG.md.

1 Like

C’est un poil plus subtil. C’est 2 semaines tant que l’on en fait pas une release il me semble.

Qu’est-ce qui te fait penser ça ?
Dans ce cas, qu’est-ce qui expliquerait que les artefacts de la v1.7.16 aient disparus deux semaines après la date de publication ?


J’avais déjà rencontré ce problème avec une publication précédente.

En tout cas la doc est assez claire sur ce point.

Je pensais que c’était cela, mais en effet en regardant l’historique du fichier .gitlab-ci je ne vois jamais de cas où les artefacts sont conservés sans péremption.

Du coup la solution de mettre 6 mois c’est bien, mais pourquoi pas retirer complètement l’expiration dans le cas de releases officielles ?

Je pense que c’est mieux de ne pas sauvegarder tous les artefacts. Ça risque d’occuper beaucoup de place sur notre serveur. Et au pire, si on a besoin de générer de nouveau des artefacts, pour des tests ou autre, on a ce système en place prêt pour les générer aisément.