* Guide de contribution et de développement du serveur NALC
- Note taken on [2020-10-10 sam. 12:28] \\
Les examples de commandes à taper dans le terminal commencent avec le symbole '$'.
Le résultat des commandes sera affiché juste en dessous de la commande tapé.
- Note taken on [2020-10-09 ven. 00:12] \\
Pour les exemples donnés dans le guide nous serons l'utilisateur Sam.
** Créer son compte gitea
Vous voulez contribuer, proposer vos corrections ou tester de nouvelles fonctionnalités ?
Vous êtes au bon endroit.
Pour commencer, créez-vous un compte sur le serveur de dépôts git que je met à disposition à cette adresse : [[https://sys4.fr/gitea]]
Une fois inscrit vous pouvez vous connecter et ainsi commencer votre participation.
** Créer des tickets de bugs
Si vous constatez un bug sur le serveur NALC vous pouvez déjà le rapporter directement en jeux avec la commande /report. Cette manière de faire est en général réservée aux joueurs qui n'ont pas de connaissances en développement.
Pour ceux voulant contribuer de façon plus pointue, ou pour les personnes déjà contributrices en développement ou voulant le devenir, poster des tickets de bugs directement depuis l'interface de Gitea sera plus approprié et confortable.
*** Où poster les tickets
Pour des raisons pratiques les tickets concernants un bug du jeux ou qui semble provenir d'un mod en particulier, seront à poster dans le dépôt [[https://sys4.fr/gitea/nalc/nalc-server-mods/issues][nalc-server-mods]] de l'organisation [[https://sys4.fr/gitea/nalc][Notre Ami Le Cube]].
Pour les bugs qui concernent la gestion ou l'administration de serveur en lui-même (exemple : un bug avec le script d'installation) vous devrez les poster dans le dépôt [[https://sys4.fr/gitea/nalc/nalc-server/issues][nalc-server]] de l'organisation [[https://sys4.fr/gitea/nalc][Notre Ami Le Cube]].
** Créer et installer *sa* version de NALC
Ici sera décrite l'installation du serveur avec l'intention de pouvoir proposer ses modifications (Pull Requests ou PR en abrégé). Donc cela sous-entend que vous devrez travailler sur vos propres bifurcations des dépôts que vous voudrez modifier (forks).
Si vous êtes juste curieux et souhaitez tester la version de développement officielle sans vouloir apporter de modifications, reportez-vous au guide d'administration du serveur qui contient un chapitre sur l'installation du serveur.
*** Bifurquer les dépôts essentiels de NALC
Pour commencer, connectez vous avec votre identifiant sur [[https://sys4.fr/gitea][le serveur de dépôts git]].
Puis rendez-vous sur le dépôt [[https://sys4.fr/gitea/nalc/nalc-server]].
Faites une *bifurcation* du dépôt :
[[file:nalc-dev-001.png]]
Faites la même opération avec les dépôts suivants :
*** Faire l'installation du serveur avec vos dépôts
Toujours depuis votre terminal, faire l'installation de la branche dev du serveur:
#+begin_example :src shell
$ cd ~/nalc-server
$ ./install.sh --url https://sys4.fr/gitea/Sam dev
#+end_example
*** Configuration de fichiers
Après l'installation il faut configurer quelques fichiers.
**** minetest.conf
Changer la valeur "name = sys4" par "name = Sam" pour définir le joueur qui sera l'administrateur.
**** start.sh
Dans ce script bash, changer les variables suivantes avec ces valeurs :
- serverpath="/home/Sam/nalc-server"
- world="$serverpath/minetest/worlds/nalc-dev"
Plus bas, dans la commande qui lance ./minetestserver changer le port (--port ...) avec la valeur *30000*
**** shutdown.sh
Dans ce script bash, changer les variables suivantes avec ces valeurs :
- serverpath="/home/Sam/nalc-server"
- world="nalc-dev"
- branch="dev"
**** backup.sh (optionnel)
À modifier comme souhaité si vous voulez utiliser cette fonctionnalité.
Ce script en l'état ne permet de sauvegarder un serveur que si le backend utilisé est postgresql.
*** Désactiver le mod irc et irc_commands
Je prends cet exemple car c'est celui que vous serez amené à faire le plus souvent et que je recommende fortement d'ailleurs. Bien sûr cela peut s'appliquer à tous les mods que vous souhaitez désactiver.
Il faut éditer le fichier *upgrade.sh* vers la ligne *108* pour y ajouter dans la variable *mods* la liste des mods à désactiver. Voici un extrait de ce à quoi cela doit ressembler :
Ensuite appliquer le changement qui restera permanent en exécutant le script upgrade de la façon suivante :
#+begin_example :src shell
$ ./upgrade.sh -w nalc-dev -b dev -f worldmt
#+end_example
Le fichier *world.mt* a été regénéré pour vous par le script.
Plus tard, si le fichier *world.mt* devait être régénéré pour une autre raison, vous n'aurez pas à vous soucier de la désactivation de ces mods puisque mémorisés dans le script.
Pour les réactiver il faudra simplement les supprimer du script puis éxécuter le script de nouveau comme précédemment.
*** Changer le backend de la map (optionnel)
Le backend de la map est configuré par défaut pour être en *leveldb*, à moins que vous ayez choisis de faire l'installation avec un backend en *potgresql*.
Libre à vous de changer le backend par ce que vous souhaitez tant que vous n'avez pas encore lancé le serveur.
Pour ce faire, éditez le fichier *world.mt* qui se trouve dans le dossier racine du serveur (là où vous êtes déjà normalement), puis changer le backend par une autre valeur comme *sqlite3* par exemple.
Quand vous aurez modifié ce fichier, il faut l'appliquer à votre world.
Pour cela il faut lancer le script *upgrade.sh* de nouveau de la même manière que précédemment :
#+begin_example :src shell
$ ./upgrade.sh -w nalc-dev -b dev -f worldmt
#+end_example
** Lancer le serveur
Vous êtes prêt pour le démarrage du serveur.
Vous pouvez le faire de deux manières. Soit de manière classique soit à l'aide du script *shutdown.sh*
Pour arrêter le serveur il vous suffira de faire les touches *[CTRL+C]* du clavier.
*** Avec shutdown.sh
Oui ça peut paraître bizarre mais de lancer le serveur avec ce script permettra de le lancer en arrière plan et il vous rendra la main sur votre terminal.
De plus, si le serveur lancé de cette façon venait à crasher plus tard, il sera relancé automatiquement au bout de 25 secondes.
Le rôle premier de ce script est d'éteindre proprement le serveur, mais permet aussi de le relancer. C'est ce que nous allons faire, même si le serveur n'a pas encore démarré.
Ce script est pratique pour être lancé en tâche cron au démarrage de votre ordinateur.
#+begin_example :src shell
$ ./shutdown.sh -r
#+end_example
Au bout de quelques secondes, vous vous retrouverez à nouveau sur le prompt de votre terminal pendant que le serveur est entrain de se lancer en arrière plan.
Dans ce contexte pour voir les logs du serveur en temps réèl vous pouvez lancer la commande suivante depuis n'importe quel terminal :
#+begin_example :src shell
$ tail -f ~/nalc-server/logs/moredebug.log
#+end_example
Pour arrêter le serveur :
#+begin_example :src shell
$ ./shutdown.sh
#+end_example
** Développer le serveur
Vous avez réussi à lancer votre propre fork du serveur, mais celui-ci est identique à l'original pour le moment et n'intègre pas encore vos corrections ou les changements qui vous tiennent tant à coeur.
Au travers de l'exemple suivant, voici une méthode pour modifier un mod que vous aurez bifurqué (fork) et que vous intégrerez à votre serveur.
Puis vous demanderez à ce que cette modification soit fusionnée dans le dépôt officiel de NALC avec la fonction *demande d'ajout* proposé par gitea. C'est l'équivalent des /Pull Requests/ de GitHub.
*** Modifier un mod
- Note taken on [2020-10-10 sam. 10:04] \\
Pour illustrer les exemples suivants, nous modifierons le mod riesenpilz toujours en tant qu'utilisateur Sam.
**** Déterminer le dépôt d'origine du mod
Cette étape est importante car vous devez travailler sur une bifurcation du dépôt d'origine.
La commande suivante permet de connaître l'url du dépôt d'origine.
#+begin_src sh
$ cd ~/nalc-server/nalc-server-mods/riesenpilz
$ git remote get-url origin
https://sys4.fr/gitea/nalc/riesenpilz.git
#+end_src
**** Bifurcation du mod
Maintenant que vous connaissez l'url du mod à bifurquer, connectez-vous sur votre compte gitea puis rendez-vous sur la page du dépôt en question. Pour l'exemple il s'agira donc du dépôt https://sys4.fr/gitea/nalc/riesenpilz
Faites la bifurcation du mod pour créer votre propre copie :
[[file:nalc-dev-001.png]]
Si nous reprenons l'exemple avec le mod riesenpilz et l'utilisateur Sam, vous devriez obtenir votre propre mod bifurqué accessible à l'adresse suivante : https://sys4.fr/gitea/Sam/riesenpilz.git
**** Intégrer le mod bifurqué dans votre copie de NALC
Actuellement le submodule git riesenpilz de dépôt nalc-server-mods pointe toujours vers le dépôt d'origine. Il faut changer cela afin que le submodule puisse être synchronisé avec votre propre bifurcation.
Et enfin pousser le commit (push) pour synchroniser le serveur.
#+begin_src
$ git push
#+end_src
**** Modifier le mod
Ça y est, votre environnement est presque prêt pour que vous puissiez commencer à modifier le code de votre mod bifurqué.
Avant d'éditer son code, mettez vous sur sa branche principale ou créez-en une nouvelle car actuellement vous êtes certainement sur une branche détachée (HEAD détachée) du dépôt qui n'a aucun lien avec la branche distante.
Dans cet exemple nous nous mettons sur la branche master :
#+begin_src sh
$ cd ~/nalc-server/nalc-server-mods/riesenpilz
$ git status
HEAD détachée sur 2a8d3aa
rien à valider, la copie de travail est propre
$ git checkout master
Basculement sur la branche 'master'
Votre branche est à jour avec 'origin/master'.
#+end_src
Maintenant vous pouvez éditer le code avec votre éditeur favoris puis enregistrez vos modifications.
Puis vous relancez le serveur pour tester vos modifications.
#+begin_src sh
$ cd ~/nalc-server
$ ./shutdown.sh -r
#+end_src
Si tout va bien et que vous êtes satisfait de votre test, vous voudrez sûrement commiter vos changements :
#+begin_src sh
$ cd ~/nalc-server/nalc-server-mods/riesenpilz
$ git status
Sur la branche master
Votre branche est à jour avec 'origin/master'.
Modifications qui ne seront pas validées :
(utilisez "git add <fichier>..." pour mettre à jour ce qui sera validé)
(utilisez "git restore <fichier>..." pour annuler les modifications dans le répertoire de travail)
modifié: init.lua
aucune modification n'a été ajoutée à la validation (utilisez "git add" ou "git commit -a")
Vous avez fait vos modifs, les avez testées et avez commité votre code. Mais cela n'a été fait qu'au niveau de vos dépôts locaux. Vous avez besoin de pousser (push) vos commits pour qu'ils soient publiés sur le serveur git :
#+begin_src sh
$ git push
Username for 'https://sys4.fr': Sam
Password for 'https://samedi@monemail.fr':
Énumération des objets: 5, fait.
Décompte des objets: 100% (5/5), fait.
Compression par delta en utilisant jusqu'à 12 fils d'exécution
Comme nous avons fait la modification du sous-module riesenpilz et que celui-ci pointe vers une nouvelle référence, il faut également mettre à jour le dépôt git parent, soit le dépôt nalc-server-mods :
#+begin_src sh
$ cd ~/nalc-server/nalc-server-mods
$ git status
Sur la branche dev
Votre branche est en avance sur 'origin/dev' de 1 commit.
(utilisez "git push" pour publier vos commits locaux)
Modifications qui ne seront pas validées :
(utilisez "git add <fichier>..." pour mettre à jour ce qui sera validé)
(utilisez "git restore <fichier>..." pour annuler les modifications dans le répertoire de travail)
modifié: riesenpilz (nouveaux commits)
aucune modification n'a été ajoutée à la validation (utilisez "git add" ou "git commit -a")
Voilà vos modifications sont bel et bien publiées et de façon correcte sur le serveur git.
*** Proposer une demande d'ajout (Pull Request)
Maintenant vous vous dites que votre contribution vaudrait le coup d'être proposée au mainteneur du serveur NALC officiel pour qu'elle soit appréciée par le plus grand nombre.
Voici comment proposer vos modifications en créant une demande d'ajout au mainteneur du dépôt officiel pour qu'il puisse les fusionner s'il est d'accord.
Les demandes d'ajouts que vous proposerez ne doivent pas concerner le dépôt nalc-server-mods mais bien ses sous-modules, donc les mods eux-mêmes directement.
Il serait trop compliqué d'expliquer exactement pourquoi ici mais c'est un sujet qui peut être discuté sur le salon irc #NALC-DEV du serveur par exemple.
Prenons l'exemple du mod riesenpilz que vous avez modifié précedement.
Lors de son push vous aurez peut-être remarqué le message suivant :
#+begin_example
remote: Create a new pull request for 'Sam:master':
En fait, une demande d'ajout a été créé automatiquement pour fusionner vos modifications au dépôt d'origine de votre fork.
Mais vous devez valider ce PR pour qu'il soit actif et que le mainteneur du dépôt d'origine soit prévenue. Pour cela, à l'aide de votre navigateur web, vous devez vous rendre à l'url indiqué soit : https://sys4.fr/gitea/nalc/riesenpilz/compare/master...Sam:master
Vous pouvez vous y rendre également en allant sur la page du dépôt d'origine (pas le vôtre, c'est important) puis aller à l'onglet demande d'ajouts.
Normalement la demande d'ajout devrait indiquer la fusion de la branche master de votre dépôt vers la branche master du dépôt d'origine.
Pour confirmer cette demande d'ajout, cliquer sur le bouton "Nouvelle demande d'ajout" puis remplissez le formulaire qui s'affiche pour rajouter une description à votre PR. Une discussion avec le mainteneur du dépôt cible pourra alors s'engager si il souhaite avoir des précisions ou faire des commentaires.
Ensuite libre à lui de fusionner votre PR ou non.
En tout cas de votre côté vous avez finalisé votre demande d'ajout.
Si votre but est de proposer vos contributions pour la version officielle du serveur alors vous devrez merger les nouvelles mises à jour dans vos propres dépôts.
Cette étape est importante car vous devez proposer vos modifications basées sur du code à jour.
La règle est qu'avant d'entâmer une modification dans un dépôt, assurez-vous avant, de le mettre à jour avec la version officielle.
*** Mettre à jour nalc-server
Rendez-vous avec votre terminal dans le dépôt de votre version de nalc-server :
#+begin_example
$ cd ~/nalc-server
#+end_example
Ajoutez le dépôt distant officiel de nalc comme dépôt distant secondaire (à faire qu'une seule fois) puis synchronisez votre dépôt local :
#+begin_example
$ git remote add nalc https://sys4.fr/gitea/nalc/nalc-server.git # À faire une seule fois
$ git fetch nalc # À faire à chaque fois que vous voulez vérifier la présence de mises à jours.
Si un éventuel conflit est détecté pendant la fusion, git vous en avertira en mentionnant quels fichiers sont en conflits.
Une fois que vous aurez résolu le conflit, vous pourrez finaliser la fusion avec la commande :
#+begin_example
$ git merge --continue
#+end_example
La fusion est terminée pour ce dépôt et le serveur est synchronisé.
Faites la commande *git log* pour le vérifier.
*** Mettre à jour nalc-server-mods
Le début est à peu près la même chose. Voici la liste des commandes à faire.
Cette fois je ne met pas le résultat des commandes pour simplifier la lecture.
#+begin_example
$ cd nalc-server-mods
$ git remote add nalc https://sys4.fr/gitea/nalc/nalc-server-mods.git # Si première fois
$ git fetch nalc
$ git log --all
#+end_example
En revanche, les choses vont se compliquer à partir de maintenant.
Quand vous allez fusionner la branche dev du dépôt officiel avec votre branche dev, les sous-modules de votre dépôt ne se mettrons pas à jour automatiquement et il faudra le faire manuellement.
#+begin_example
$ git merge nalc/dev
Échec de fusion du sous-module riesenpilz (commits non présents)
Fusion automatique de riesenpilz
CONFLIT (sous-module) : Conflit de fusion dans riesenpilz
La fusion automatique a échoué ; réglez les conflits et validez le résultat.
$ git status
Sur la branche dev
Votre branche est à jour avec 'origin/dev'.
Vous avez des chemins non fusionnés.
(réglez les conflits puis lancez "git commit")
(utilisez "git merge --abort" pour annuler la fusion)
Modifications qui seront validées :
modifié: WorldEdit
modifié: homedecor_modpack
modifié: mesecons
modifié: mobs
modifié: moreblocks
Chemins non fusionnés :
(utilisez "git add <fichier>..." pour marquer comme résolu)
modifié des deux côtés : riesenpilz
Modifications qui ne seront pas validées :
(utilisez "git add <fichier>..." pour mettre à jour ce qui sera validé)
(utilisez "git restore <fichier>..." pour annuler les modifications dans le répertoire de travail)
modifié: WorldEdit (nouveaux commits)
modifié: homedecor_modpack (nouveaux commits)
modifié: mesecons (nouveaux commits)
modifié: mobs (nouveaux commits)
modifié: moreblocks (nouveaux commits)
#+end_example
De plus, et c'est notre cas ici aussi, vous aurez très certainement des conflits avec les sous-modules que vous aurez bifurqués auparavant et qui ont bénéficié de nouveaux commits dans les dépôts officiels. Peu importe que ces nouveaux commits soient issus de vos PR ou non.
Mais *Pourquoi ?*
Les sous-modules que vous avez modifiés, donc que vous avez bifurqués ne sont pas référencés à la même URL que les sous-modules officiels. L'historique de la branche dev de votre dépôt nalc-server-mods a dévié par rapport à la branche officielle qui elle ne connaît pas l'historique de votre dépôt puisqu'il n'a pas été fusionné. Du coup git considère que c'est un conflit et ne fera pas le merge automatiquement car il n'a pas moyen de savoir quoi faire. C'est à vous de décider.
*Dans notre cas que faire concrètement ?*
Pour nous sortir de ce mauvais pas nous allons pour chaque sous-module en conflit faire une fusion de la branche master du dépôt d'origine du sous-module puis nous ajouterons notre sous-module modifié à la fusion du dépôt nalc-server-mods.
#+begin_example
$ cd riesenpilz
$ git remore add nalc https://sys4.fr/gitea/nalc/riesenpilz.git # Si première fois
$ git fetch nalc
$ git log --all
$ git merge nalc/master
# Réglez les éventuels conflits
$ git push origin master
$ cd ..
$ git add riesenpilz
$ git status
Sur la branche dev
Votre branche est à jour avec 'origin/dev'.
Tous les conflits sont réglés mais la fusion n'est pas terminée.
(utilisez "git commit" pour terminer la fusion)
Modifications qui seront validées :
modifié: WorldEdit
modifié: homedecor_modpack
modifié: mesecons
modifié: mobs
modifié: moreblocks
modifié: riesenpilz
Modifications qui ne seront pas validées :
(utilisez "git add <fichier>..." pour mettre à jour ce qui sera validé)
(utilisez "git restore <fichier>..." pour annuler les modifications dans le répertoire de travail)
modifié: WorldEdit (nouveaux commits)
modifié: homedecor_modpack (nouveaux commits)
modifié: mesecons (nouveaux commits)
modifié: mobs (nouveaux commits)
modifié: moreblocks (nouveaux commits)
#+end_example
Le sous-module riesenpilz corrigé apparaît maintenant dans les modifications qui seront validés pour la fusion en attente que nous pouvons maintenant terminer.
#+begin_example
$ git merge --continue
$ git status
Sur la branche dev
Votre branche est en avance sur 'origin/dev' de 2 commits.
(utilisez "git push" pour publier vos commits locaux)
Modifications qui ne seront pas validées :
(utilisez "git add <fichier>..." pour mettre à jour ce qui sera validé)
(utilisez "git restore <fichier>..." pour annuler les modifications dans le répertoire de travail)
modifié: WorldEdit (nouveaux commits)
modifié: homedecor_modpack (nouveaux commits)
modifié: mesecons (nouveaux commits)
modifié: mobs (nouveaux commits)
modifié: moreblocks (nouveaux commits)
aucune modification n'a été ajoutée à la validation (utilisez "git add" ou "git commit -a")
#+end_example
Il ne nous reste plus qu'à mettre à jour les sous-modules bénéficiants de nouveaux commits puis on pousse notre branche dev sur le serveur :
#+begin_example
$ git submodule update
Chemin de sous-module 'WorldEdit' : '418a30c89e426f769365dd2955fcde1c0f35adb7' extrait
Chemin de sous-module 'homedecor_modpack' : 'b6ecc0b95f322a391b87341d4321cb1c67da30c2' extrait
Chemin de sous-module 'mesecons' : 'd356f901a3c26f2cce28ce0be64d26fff996e110' extrait
Chemin de sous-module 'mobs' : '7f4d473feef7ab6df20d00e5ceaba8335efd463a' extrait
Chemin de sous-module 'moreblocks' : 'b93949c26629489f586df9bdda5a9eb9fc977d34' extrait
$ git status
Sur la branche dev
Votre branche est en avance sur 'origin/dev' de 2 commits.
(utilisez "git push" pour publier vos commits locaux)
