Salut Camille,
lorsque je clone ce repertoire
https://git.spip.net/spip-contrib-extensions/formidable_participation
j'ai bien un tag v1.9.0
Par contre Gitea ne l'affiche pas (et du coup je pense que le débardeur
ne le trouve pas).
Quid?
Maïeul
Si, si, il est bien présent
https://git.spip.net/spip-contrib-extensions/formidable_participation/src/tag/v1.9.0
(l’interface est un peu trompeuse… dans le menu déroulant, faut faire un clic sur “Branches” ou “Tags” selon ce qu’on veut lister, puis faire son choix)
> j'ai bien un tag v1.9.0
>
> Par contre Gitea ne l'affiche pas (et du coup je pense que le
> débardeur
> ne le trouve pas).Si, si, il est bien présent
(l'interface est un peu trompeuse… dans le menu déroulant, faut faire
un clic sur "Branches" ou "Tags" selon ce qu'on veut lister, puis
faire son choix)
hum, mais il est pas ici
on le trouve pas non plus sur
plugins.spip.net, alors que normalement le débardeur est censé s'appyuer
sur les tags...
c'est bizarre
[...]
[...]
hum, mais il est pas ici
ça c'est pas automatix ^^
on le trouve pas non plus sur
plugins.spip.net, alors que normalement le débardeur est censé s'appyuer
sur les tags...c'est bizarre
les tags oui, pas les releases.
mais en effet, étrange qu'il soit pas débardé ; faut patienter un peu
…ou Cerdic peut nous en dire plus ?
[...]
> >
[...]
> hum, mais il est pas ici
>
>
>
ça c'est pas automatix ^^
bah pourquoi pour les autres projets on a dans releases ?
> on le trouve pas non plus sur
> plugins.spip.net, alors que normalement le débardeur est censé
> s'appyuer
> sur les tags...
>
> c'est bizarre
>les tags oui, pas les releases.
il me semblat que dans gitea, comme dans github, il n'y avait pas de
distinction tags/release, et quand bien même ce serait le cas, le
debardeur s'appuie normalement sur les tags (si j'ai bien compris le
message de présenattion=
On a déjà dit dans l'autre fil que le concept de "release" n'avait aucun rapport avec Git, c'est propre à chaque forge. Github génère automatiquement une release à chaque tag, de ce que quelqu'un avait dit il me semble, et donc ya plus qu'à rajouter un texte de présentation (souvent le changelog synthétique). Mais pas Gitea à priori. Et j'ai l'impression que quand on est pas admin on peut pas le faire (moi je vois aucun bouton pour ça avec mon compte), tout comme la personnalisation des étiquettes de tickets et des jalons…
Mais ya pas à le faire puisqu'on n'utilise pas ce concept. Et cet onglet pourrait être enlevé à mon avis car c'est pas avec ça qu'on distribue et communique, mais avec le débardeur qui fait les paquets et les envoie sur le site grand public. Sur la forge les tags seuls suffisent. Après je sais pas pourquoi là il ne l'a pas encore pris en compte…
Ah si effectivement, dans les autres projets, les simples tags apparaissent aussi dans release… Bon bah faut demander à azerttyu plutôt alors 
Alors je viens de regarder.
Le debardeur se fie a la date de dernière modification de chaque projet donnée par l’API gitea pour savoir si il doit redemander la listes de tags d’un projet.
Mais subtilité : quand on pose juste un tag ça ne compte visiblement pas pour impacter la date de modification d’un projet en tout cas vu par l’API gitea.
Donc le debardeur se dit qu’il n’y a rien de nouveau à aller voir et ne remets pas à jour la liste des tags.
Je vais regarder pour mettre un delai maxi de cache à cet endroit : même si le projet ne semble pas avoir bougé, si on a cache de plus de Xheures on redemande la liste des tags
(Alternative : il suffit de pusher un commit pour débloquer la situation, la légende urbaine à propos de smart paquet devient vraie avec le debardeur)
Bref, ici j’ai forcé manuellement, le tag est descendu, il va remonter sur plugins.spip rapidement maintenant
merci pour ces précisions.
Sans doute la même raison de non actualisation par push de tags qui fait
que
ne liste rien.
Enfin, à creuser du coup, mais c'est plus un problème de gitea.
Alors je viens de regarder.
Le debardeur se fie a la date de dernière modification de chaque
projet donnée par l’API gitea pour savoir si il doit redemander la
listes de tags d’un projet.
Mais subtilité : quand on pose juste un tag ça ne compte visiblement
pas pour impacter la date de modification d’un projet en tout cas vu
par l’API gitea.
Donc le debardeur se dit qu’il n’y a rien de nouveau à aller voir et
ne remets pas à jour la liste des tags.Je vais regarder pour mettre un delai maxi de cache à cet endroit :
même si le projet ne semble pas avoir bougé, si on a cache de plus de
Xheures on redemande la liste des tags(Alternative : il suffit de pusher un commit pour débloquer la
situation, la légende urbaine à propos de smart paquet devient vraie
avec le debardeur)Bref, ici j’ai forcé manuellement, le tag est descendu, il va remonter
sur plugins.spip rapidement maintenant--
Cédric
> [...]
> > >
> [...]
> > hum, mais il est pas ici
> >
> >
oui, j'aurais pas regardé là sinon
> Mais pas Gitea à priori.
Ah si effectivement, dans les autres projets, les simples tags apparaissent aussi dans release…
Je maintiens que ce n'est pas automatique…
…Puisque, par définition, tu choisis quand tu veux faire ta sortie et
sur quel tag avec le reste (le/a texte/description, le nom/titre qui
peut ne pas être celui du tag, les assets complémentaires …que la
forge ne peut pas deviner)
Et j'ai des tags sans releases, les releases que j'ai ont été créés manuellement
Et comme dit la doc, on peut scripter un automatisme ou utiliser un
déclencher-pousseur
Et comme dit la doc, on peut scripter un automatisme ou utiliser un
déclencher-pousseur
Exemple d'outil pour Gitea (on se base sur celui de CI-CD)
Ce genre d'extension utilise bien entendu les API dispos
Bonjour
le tag est présent
https://git.spip.net/spip-contrib-extensions/formidable_participation/src/tag/v1.9.0
Km
Salut
Je complète si "tag" et "release" étaient la même on ne s’embêterait
pas à avoir 2 onglets distincts.
Le reste a déjà été dans ce fil de discussion et d'autres
Km
Explique moi alors pourquoi, alors que rien n'a été configuré pour, gitea considère sur certains projets les tags comme des releases et pas sur d'autres?
Oki, mais alors pourquoi sur certains projets pusher des tags crée automatiquement des releases, et pas sur d'autres?
Salut
Me faudrait des exemples. Ma boule de cristal est en panne
https://git.spip.net/spip-contrib-extensions/formidable/releases
https://git.spip.net/spip-contrib-extensions/spip-bible/releases
et on pourrais en citer d'autres
tu as ici des versions correspondantes aux tags envoyés
https://git.spip.net/spip-contrib-extensions/formidable_participation/releases
tu n'as pas les versions correspondantes aux tags envoyés
Bonjour
Ils ont été importés via l'api de gitea. De ce que je vois ce sont des tags pre-éxistants à l'usage de git.
Ils n'ont pas été créés par un git push --tags par exemple.
Km
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