Re: Tag sur git mais pas sur gitea

Bonjour

Cela devrait être réglé, maieul a identifié une commande serveur qui 
permet de créer à la volée les release sur la base des tags.

La commande semble avoir fonctionné.

Km

Le 09/04/2020 à 12:34, Maïeul Rouquette a écrit :
> Yep, ca me serait pas venu à l'idée :)
> Le jeudi 09 avril 2020 à 12:31 +0200, cam.lafit a écrit :
>> Salut
>> Ok donc c'est passé lors de la dernière mise à jour que j'ai poussé.
>> Comme on était sur une alpha ce n'était pas identifié dans le
>> changelog.
>> Autrement INTERDICTION de faire le dirty push indiqué dans le ticket
>> de référence. Merci de ne pas chercher à casser les outils
>> actuellement en place et la synchronisation svn.
>> Merci
>> Le 09/04/2020 à 11:53, nicod_ a écrit :
>>> Le 09/04/2020 à 11:24, Maïeul a écrit :
>>>> Le 09/04/2020 à 11:19, Maïeul Rouquette a écrit :
>>>>> Hum, je peux t'assurer que pour formidable, comme c'est moi qui
>>>>> les
>>>>> avais poussé à l'époque, c'était bien du git push --tags. Ca
>>>>> avait même
>>>>> fait crier puisque cela avait provoqué plein, plein de commits
>>>>> svn :)
>>>>> Le jeudi 09 avril 2020 à 11:17 +0200, cam.lafit a écrit :
>>>>   
>>>> il y avait un bug avant, mais corrigé
>>>> https://github.com/go-gitea/gitea/issues/6237
>>>>
>>>> En tout cas à lire les messages sur ce fil, il semblerait quand
>>>> même que la logique dans gitea soit un tag = une release
>>>   
>>> J'ai créé hier un nouveau dépot sur spip-contrib-extensions :
>>> https://git.spip.net/spip-contrib-extensions/opquast
>>>
>>> Après avoir poussé le code dans le dépôt, j'ai créé un tag
>>> localement (git tag -a v1.0.0 -m "Version 1.0.0" et git push), et ça
>>> a bien créé une release côté Gitea, automatiquement.
>>>
>>> (et je vois qu'il a bien été débardé, super !)
>>>