Version 8 — Avril 2020 — JLuc
N’hésitez pas à répondre aux questions sans réponse.
< faq >
? Comment mettre à jour le zip d’un plugin ?
Il faut créer un nouveau tag git et le « débardeur » se charge ensuite de mettre à jour le zip, qui sera proposé dans la partie privée de votre SPIP. Il n’y a pas d’interface gitea pour créer un tag et il faut donc le faire par la ligne de commande.
Exemple : pour créer un nouveau tag 1.., se mettre dans le dossier source racine du plugin, et faire :
git tag -a v1.. -m "Version 1.."
git push
git push -- tags
</ code push</code >
Si vous voulez, vous pouvez paramétrer votre git pour éviter cette dernière étape : ouvrez votre ficheir <code>~/.Pour pusher aussi les tags quand on <code>git push
: ouvrir votre /.gitconfig</code > gitconfig et assurez vous assurer qu’il y a dedans :
[push]
default = simple
followTags = true
Avec ce paramétrage , il suffit de faire < code>git push</code >.
? Faut il économiser les tags ?
Non, il faut créer un tag chaque fois que c’est utile, c’est à dire chaque fois qu’on veut mettre à disposition des utilisateurs une nouvelle version du plugin.
Sous git, créer un tag n’a qu’un très faible coût.
? Comment paramétrer git en local ?
Une bonne partie de la config proposée par Delicious Insight peut être reprise ainsi que leur prompt (un peu adapté), super utile : https://delicious-insights.com/fr/articles/apprendre-git (dans Installation et Configuration>configuration partagée")
? Comment importer sur git.spip.net un plugin développé sur github ou gitlab ?
Il y a 2 manières de faire : en cliquant un bouton (simple et automatique) ou en ligne de commande (personnalisable au besoin).
- Automatiquement : sur git.spip.net, chacun peut trouver, à coté de son avatar, une opération appelée « Nouvelle migration ». Elle permet en un seul formulaire de transférer un repo github ou autre vers son organisation personnelle sur la forge ou dans une des organisation spip-contrib.
- En ligne de commande : Chaque repo git, qu’il soit distant ou local, possède un historique, et qu’on peut synchroniser les historiques entre les repos
Pour importer un repo github ou gitlab sur git.spip.net,
git remote add <unnomdetonchoix> <lurldureposdistant>
. <unnomdetonchoix>
est le nom qui permet de référencer (depuis ton repos local) le repos distant nouvellement créé. Mais si en fait tu souhaites ne garder qu’un seul dépot distant comme dépot de référence, plutôt qu’ajouter la nouvelle url à l’url existante, tu peux aussi simplement la remplacer : git remote set-url origin <lurl du repos distant>
.git push <unnomdetonchoix>
Rq : Par convention, lorsqu’on clone une depot distant, il est référencé avec le nom origin
comme dépot local. Mais tu peux en référencer plusieurs.
Une pratique courante est
- upstream
pour désigner le repos communautaire officiel du projet
- origin
pour designer le repos distant « personnel »
? Est-ce une bonne pratique de récupérer le code de tous les plugins de la zone ?
Pour ne pas surcharger le serveur, il ne faut cloner localement que les plugins dont on a besoin.
Donc si vous n’avez pas besoin de tous les plugins, ne clonez pas tous les plugins.
Dans certains cas toutefois, on a parfois besoin des sources de tous les plugins, par exemple pour faire des recherches globalement sur tout le code afin d’étudier les cas d’usages d’une fonction ou pour corriger tous ces appels.
? Comment être notifié des modifications apportées sur un plugin, ou ne pas l’être ?
Toute personne inscrite sur git.spip.net est abonnée à l’ensemble des dépôts.
Cet abonnement à maintenant l’effet de vous notifier des divers échanges (tickets, PR, ...) qui ont lieu sur ces divers dépôts.
Ceci est dû au fait que par défaut à la création de votre compte, celui ci est configuré pour que toutes les notifications vous soient envoyées.
Vous pouvez personnaliser cette configuration depuis https://git.spip.net/user/settings/account
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...