| ... | ... | @@ -4,14 +4,14 @@ Ce document vise à donner quelques clés d'utilisation de Gitlab pour signaler |
|
|
|
|
|
|
|
* Gitlab est un outil qui s'adresse initialement aux développeurs. La remontée de bugs est une de ses fonctionnalités, mais pas la seule. Il y a donc de nombreuses fonctionnalités que nous n'utiliserons pas.
|
|
|
|
|
|
|
|
* Sur Gitlab, ce que nous appelons bug sera signalé par une **issue**.
|
|
|
|
* Sur Gitlab, un bug sera signalé par une **issue**.
|
|
|
|
|
|
|
|
* Sur Gitlab, vous aurez la possibilité de modifier ou supprimer le contenu écrit par quelqu'un d'autre. **Merci de ne pas le faire et de toujours passer par les commentaires** si besoin d'ajouter des précisions ou de contredire une information.
|
|
|
|
|
|
|
|
* Tous les textes que vous écrirez sur Gitlab seront interprétés en **Markdown** (cf. [ce lien](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) pour plus d'informations). Le texte peut ainsi être formaté, même si ça n'aura pas forcement grande utilité reporter les bugs. C'est en tout cas ce qui m'a permis de mettre en forme ce wiki, avec des titres des éléments en gras etc. La contrepartie est que certains formatage ne sont pas très intuitifs, notamment **le retour à la ligne**. En Markdown, pour s'assurer qu'un retour à la ligne sera pris en compte, il faut :
|
|
|
|
* Tous les textes que vous écrirez sur Gitlab seront interprétés en **Markdown** (cf. [ce lien](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) pour plus d'informations). Le texte peut ainsi être formaté, même si ça n'aura pas forcement grande utilité reporter les bugs. C'est par exemple ce qui m'a permis de mettre en forme ce wiki. La contrepartie est que certains formatage ne sont pas très intuitifs, notamment **le retour à la ligne**. En Markdown, pour s'assurer qu'un retour à la ligne sera pris en compte, il faut :
|
|
|
|
- soit ajouter deux espace à la fin de la ligne qui précède le retour à la ligne.
|
|
|
|
- soit laisser une ligne vide entre les deux lignes de texte (faire 2 sauts de ligne donc).
|
|
|
|
Si vous ne mettez qu'un saut de ligne et pas d'espaces à la fin de votre première ligne, la ligne du bas sera collée à la suite de la ligne du haut.
|
|
|
|
Si vous ne mettez qu'un saut de ligne et pas d'espaces à la fin de votre première ligne, la ligne du bas sera collée à la suite de la ligne du haut, sans retour à la ligne.
|
|
|
|
|
|
|
|
Lors de la rédaction de vos issues, vous pourrez aller dans l'onglet Preview pour prévisualiser le rendu de ce que vous avez écrit avant de l'envoyer.
|
|
|
|
|
| ... | ... | @@ -31,7 +31,7 @@ Dans l'onglet issues vous trouverez notamment les éléments suivants : |
|
|
|
|
|
|
|
## 2.1 - Cas 1 : créer une nouvelle issue
|
|
|
|
|
|
|
|
Avant de créer une nouvelle issue, vérifiez que le bug n'a pas déjà été reporté dans une autre issue. Si c'est le cas, passez au chapitre suivant. Sinon, vous pouvez créer une nouvelle issue en suivant ces différentes étapes :
|
|
|
|
Avant de créer une nouvelle issue, vérifiez que le bug n'a pas déjà été reporté dans une autre issue (par vous ou quelqu'un d'autre). Si c'est le cas, passez au [chapitre suivant](https://gitlab.univ-nantes.fr/pulvin-c/valpemap-suivi/-/wikis/Tuto-:-utiliser-les-issues-pour-signaler-des-bugs#22-cas-2-commenter-une-issue-existante). Sinon, vous pouvez créer une nouvelle issue en suivant ces différentes étapes :
|
|
|
|
|
|
|
|
### >1 Cliquez sur "New issue"
|
|
|
|
|
| ... | ... | @@ -44,7 +44,7 @@ Complétez les champs indiqués dans l'image ci-dessous, en respectant les conve |
|
|
|

|
|
|
|
|
|
|
|
#### >2.1 Ajoutez un titre
|
|
|
|
Pour uniformiser les titres d'issues, merci de respecter la convention suivante :
|
|
|
|
Pour uniformiser les titres, merci de respecter la convention suivante :
|
|
|
|
NOM DU MODULE : problème rencontré
|
|
|
|
|
|
|
|
*Par exemple : ENQUETE : impossible de zoomer sur la méditerranée*
|
| ... | ... | @@ -61,14 +61,14 @@ La version de l'application est indiquée en haut à gauche lorsque vous êtes s |
|
|
|
|
|
|
|

|
|
|
|
|
|
|
|
**ATTENTION : si vous avez la possibilité de créer ou de supprimer des milestones, merci de ne pas le faire et d'utiliser uniquement ceux déjà proposés.**
|
|
|
|
**ATTENTION** : si vous avez la possibilité de créer ou de supprimer des milestones, merci de ne pas le faire et d'utiliser uniquement ceux déjà proposés.
|
|
|
|
|
|
|
|
#### >2.4 Assignez une importance au bug via les labels
|
|
|
|
Les labels permettent de taguer les issues. Dans le cas de Valpemap, nous utilisons cette fonctionnalité pour définir un degré d'importance au bug soulevé.
|
|
|
|
|
|
|
|
Gitlab offre la possibilité d'assigner plusieurs labels par issue. **Dans notre cas d'utilisation, merci de n'assigner qu'un seul label par issue.**
|
|
|
|
|
|
|
|
**ATTENTION : si vous avez la possibilité de créer ou de supprimer des labels, merci de ne pas le faire et d'utiliser uniquement ceux déjà proposés.**
|
|
|
|
**ATTENTION** : si vous avez la possibilité de créer ou de supprimer des labels, merci de ne pas le faire et d'utiliser uniquement ceux déjà proposés.
|
|
|
|
|
|
|
|
### >3 Cliquez sur "Submit issue"
|
|
|
|
Et voilà, l'issue est créée et Gitlab vous montre ce à quoi elle ressemble. Elle apparait maintenant dans la liste des issues.
|
| ... | ... | @@ -93,11 +93,11 @@ Pour commenter une issue, suivez ces différentes étapes : |
|
|
|
|
|
|
|
### >2 Encodez votre commentaire
|
|
|
|
|
|
|
|
Comme pour les issues indiquer les commentaires les plus précise possible.
|
|
|
|
Comme pour les issues, indiquez les commentaires les plus précis possibles.
|
|
|
|
|
|
|
|
ATTENTION : comme pour les issues, le commentaire sera interprétée en **Markdown**. Vous pouvez vérifier le rendu de votre commentaire dans l'onglet "Preview" (cf. Chapitre 1. Généralités sur Gitlab et points d'attention).
|
|
|
|
ATTENTION : comme pour les issues, le commentaire sera interprété en **Markdown**. Vous pouvez vérifier le rendu de votre commentaire dans l'onglet "Preview" (cf. Chapitre 1. Généralités sur Gitlab et points d'attention).
|
|
|
|
|
|
|
|
ATTENTION : petit rappel, **il ne faut jamais clore une issue**.
|
|
|
|
ATTENTION : petit rappel, **il ne faut jamais clore une issue** car ceci indiquerait que le bug est résolu. Si l'issue ne vous parait plus d'actualité, indiquez le en commentaire.
|
|
|
|
|
|
|
|

|
|
|
|
|
| ... | ... | |
| ... | ... | |