Gerrit/Utilisation avancée
Les instructions de base pour configurer et travailler avec Git et Gerrit sont décrites dans le Tutoriel (voir aussi sa version raccourcie).
Avertissement
Cette page présente principalement comment faire les choses de manière la plus difficile dans Gerrit.
L'outil git review continue de s'améliorer, et contient maintenant des mécanismes intégrés pour pousser sur une branche, télécharger un ensemble de corrections dépendantes, etc.
Vous devriez probablement revoir man git review avant de décider d'aller plus loin.
Installation
Raccourci pour configurer SSH (facultatif)
Il est plus facile d'accéder au dépôt quand vous n'êtes pas obligé de spécifier à chaque fois votre nom d'utilisateur@gerrit.wikimedia.org:29418 complet.
Vous pouvez modifier votre fichier ~/.ssh/config et ajouter
Host gerrit Hostname gerrit.wikimedia.org Port 29418 User yourusername
Vous pouvez alors utiliser gerrit à la place.
git review -sajoute ungerritdistant à git ce qui rend cette étape inutile. Cscott (discussion)
Soumettre des corrections
Définir un dépôt pour git distant
La plupart des dépôts doivent déjà avoir des informations pour git-remote sur l'emplacement de votre dépôt et le nom de la branche master.
Les informations sont stockées dans un fichier .gitreview à la racine du dépôt.
Si ce fichier n'existe pas encore, vous devez le créer et le valider.
Le format est le suivant :
[gerrit]
host=gerrit.wikimedia.org
port=29418
project=operations/puppet.git
defaultbranch=production
Les champs host et project sont obligatoires.
Les autres champs sont facultatifs :
port vaut par défaut 29418.
defaultbranch vaut par défaut master.
Fusionner à nouveau votre amendement dans votre branche
Cette section est facultative. C'est une manière de vous offrir une solution pratique à un problème commun. À ce stade, votre nouvel ensemble de corrections est déjà dans Gerrit.
Après avoir amendé (amend) vos modifications, vous voudrez peut-être les réintégrer dans votre branche locale.
Vous pouvez le faire en allant à la modification Gerrit correspondante.
Voici un exemple :
https://gerrit.wikimedia.org/r/c/7669/4
Allez à la section de téléchargement (Download) et recopiez ponctuellement (cherry pick).
Nous sélectionnerons l'ensemble 4 de corrections.
Revenir sur votre branche. Vous serez sur votre branche de relecture, là où vous venez de faire vos modifications.
git checkout mingle-fr-2012-59
Collez le cherry pick et résolvez (merge) les conflits éventuels.
git fetch ssh://<USERNAME>@gerrit.wikimedia.org:29418/mediawiki/extensions/DonationInterface refs/changes/69/7669/4 && git cherry-pick FETCH_HEAD
Exécutez l'ajout dans git des fichiers modifiés.
git add payflowpro_gateway/payflowpro.adapter.php
N'oubliez pas de vérifier votre état et de faire un diff.
git diff
Vous devriez voir qu' il n' y a plus de différences :
diff --cc payflowpro_gateway/payflowpro.adapter.php
index d7e510a,738c9df..0000000
--- a/payflowpro_gateway/payflowpro.adapter.php
+++ b/payflowpro_gateway/payflowpro.adapter.php
Puis validez (commit) les changements :
git commit -m 'Merging patch set 4.'
[mingle-fr-2012-59 4e82e5a] Merging patch set 4.
1 files changed, 3 insertions(+), 3 deletions(-)
Soumettre une modification dans une branche pour relecture (backporting)
- Voir aussi Backporting fixes, une discussion sur le backporting des modifications du noyau MediaWiki (coordonné avec l'Equipe WMF Release Engineering, géré dans Phabricator, etc.)
Dans cet exemple, nous allons faire le backporting de Gerrit #Ib27792 de master vers REL1_20.
L'idée de base est d'utiliser git cherry-pick pour appliquer les corrections du commit du master sur une autre branche.
(Notez que cela peut également être fait via l'interface web de Gerrit, avec le bouton Cherry Pick).
Avant de commencer, recherchez la valeur du code de hash de la validation du merge dans le master. Vous pouvez trouver cela sur la page des modifications de Gerrit. Déroulez jusqu'au dernier ensemble de corrections, et le code de hachage de la validation Git se trouve entre "Patch Set NN" et "(gitweb)" (à ne pas confondre avec le Gerrit Change id qui commence avec un 'I' majuscule). Assurez-vous que ce commit a bien sûr été fusionné dans la branche master. Si ce n'est pas le cas, attendez qu'il soit revu et fusionné dans le master — Le commit peut encore être modifié (amend) et nous ne voulons pas fusionner une ancienne version.
$ git fetch origin
# valeur de hachage du git commit de la modification dans le ''master''
$ git show d4f2c0e8f76a7634fce1631669f4ce037965d8b5
$ git checkout origin/REL1_20
$ git reset --hard origin/REL1_20 # Assurez-vous de la dernière version, annulez toutes les dépendances locales
$ git cherry-pick d4f2c0e8f76a7634fce1631669f4ce037965d8b5
# Ne modifiez pas le message de commande. En particulier, le
# 'Change-Id' intact en bas du message, puisque c'est
# ce que Gerrit utilise pour lier le changement du 'master' à la fusion de la branche.
# Si la fusion provoque des conflits, vous devez les résoudre manuellement.
# utiliser git add <files> et exécuter git commit. Déplacez la section ''Conflicts''
# du message de commit avant ''Change-Id'', de sorte que ''Change-Id'' reste égal à
# au message en bas, sinon la poussée sera rejetée.
# Vérifier que l'historique est cohérente
$ git log --graph --decorate --oneline -n5
# Afficher la modification originale dans Gerrit et chercher le nom du sujet,
# puis utiliser-le ci-dessous au lieu de ''topic-name'', par exemple ''refs/for/REL1_20/bug/36151''
# ou ''refs/for/wmf/1.21wmf1/my-topic-name''
$ git push origin HEAD:refs/for/REL1_20/bug/36151
remote:
remote: New Changes:
remote: https://gerrit.wikimedia.org/r/25756
remote:
* [new branch] HEAD -> refs/for/REL1_20/bug/36151
- Est-ce qu'il y a un besoin particulier ici à vouloir utiliser le
git pushcompliqué à la place degit review? -- S Page (WMF) (discussion) 02:28, 17 mai 2013 (UTC)- La seule raison est pour que vous puissiez lui passer un nouvel article. Ainsi, comme alternative, après le contrôle de
git log, recherchez d'abord le nom du sujet (ou pensez à un nouveau sujet) et faitesgit checkout -b random-new-topic-namesuivi dugit review -Rhabituel (au lieu de git push); à partir de la version 1.23 de git-review, il réutilisera le sujet d'origine. git review -R remote-branch-namefonctionne également si vous voulez pousser sur une branche distante à partir d'une branche de relecture.
- La seule raison est pour que vous puissiez lui passer un nouvel article. Ainsi, comme alternative, après le contrôle de
Donne :
- https://gerrit.wikimedia.org/r/25756 est créé pour la relecture.
- Gerrit #Ib27792 affiche à la fois les modifications de l'original et celles de la fusion
Agir sur des branches distantes
Par défaut, votre clone local n'aura qu'une branche principale master locale, configurée pour suivre la branche master distante.
Suivre signifie que chaque fois que vous récupérez des objets du dépôt distant, l'état Git ou celui de la branche Git vous indiquent le niveau de mise à jour de votre branche locale, ce qui est très utile.
Donc, chaque fois que vous voulez agir régulièrement sur une branche distante (disons REMOTE_BRANCH, vous voudrez en configurer une localement (REMOTE_BRANCH aussi pour vous en souvenir facilement) qui la suive avec -t (pour tracking).
git branch -vv
donnera les détails complets :
$ git clone ...
$ git checkout -b REL1_19 -t gerrit/REL1_19
$ git branch -vv
REL1_19 3b2bfd3 [gerrit/REL1_19: ahead 1] .gitreview for REL1_19 branch
* master 13169c8 [gerrit/master: behind 1] * (bug 34212) ApiBlock/ApiUnblock a[...]
$
Pousser en utilisant la configuration automatique
git-review accepte, comme argument facultatif, le nom de la branche sur laquelle il faut agir.
Lorsque cet argument n'est pas précisé, il se replie sur la recherche du paramètre defaultbranch dans un fichier .gitreview de la racine du dépôt.
Chaque branche doit avoir un .gitreview qui indique la valeur correcte de la branche par défaut.
Pour mediawiki/core.git, soit il faut utiliser quelque chose comme : git-review BRANCH_NAME.
 | Par défaut, git-review utilise une branche 'master' qui peut ne pas être celle que vous souhaitez. Vérifier le fichier .gitreview pour être certain. |
Pousser en utilisant la configuration manuelle (Windows)
Pour modifier l'emplacement où vous poussez pour la relecture après avoir effectué une configuration manuelle, exécutez git config alias.push-for-review "push gerrit HEAD:refs/for/BRANCH_NAME" pour créer l'alias local, puis utilisez git push-for-review comme d'habitude.
Valider sur une branche non master
Pour faire une modification sur la branche 1.17, créez une branche et une balise et poussez les deux :
git checkout -b REL1_17 origin/REL1_17
<make code changes>
git add <files-changed>
git commit
git push gerrit REL1_17
git tag 1.17.3
git push --tags
Annulation partielle de validation antérieure
git show <commit> -- <path> | git apply -R
<commit> peut se trouver dans l'affichage de la correction Gerrit en petits caractères après le texte Patch Set N. Puis poussez pour relecture comme habituellement.
Défaire les dépendances erronnées (modifications rebase)
Exemple pour gerrit:5154
git fetch --all # pour nous assurer que nous avons les derniers changements git review -d Ie6e3c9be git rebase -i gerrit/master # supprimer les commits dont vous voulez vous débarrasser git commit --amend # ajouter une note git review -f # -f supprime la branche après le submit
Créer une dépendance
Si vous êtes sur le point de créer une correction qui dépend d'une autre (non fusionnée), ou si vous avez déjà soumis une correction mais que vous devez corriger sa dépendance (c'est-à-dire qu'actuellement elle est basée sur master et se casse si vous fusionnez sans la dépendance, ou peut-être que vous avez écrasé votre changement en haut de la dépendance), alors c'est la section que vous recherchez. Si vous souhaitez réparer le correctif pour qu'il ait la bonne dépendance plutôt que de créer un nouveau correctif avec une dépendance, assurez-vous que votre copie de travail est propre (pas de changements non validés).
git fetch --all # Assurez-vous d'avoir les dernières informations du dépôt
git review -d 1234 # numéro de modification Gerrit des corrections que vous souhaitez en tant que dépendance (''parent'')
Maintenant, nous devons nous assurer que le patch a le bon parent git. Selon que vous créez un nouveau patch ou que vous corrigez un patch existant, il existe deux façons différentes de faire cela. Si vous partez de rien :
git checkout -b bug/1234 # Créez une nouvelle branche, à partir de la branche actuelle (la dépendance) comme parent # Editez les fichiers : apporter vos modifications git add someFile.php some/other/file.js git commit # Validez votre patch git log -n5 --decorate --pretty=oneline # Vérifiez que les 5 dernières entrées du journal commencent maintenant par : # * (HEAD, bug/1234) votre modification # * (review/john/700) les dépendances # * (gerrit/master) git push gerrit HEAD:refs/for/master # ou git review
Si vous devez amender votre patch pour avoir la bonne dépendance :
git branch # Prenez note de la branche ''revue/*'' qui a été créée pour cela, elle possède une '*' devant elle git checkout bug/1234 # Copiez la branche de l'article local de vos modifications git rebase review/john/7000 # Le nom de la branche des modifications gerrit que nous avons extraites plus tôt # Résoudre les conflits si nécessaire, # - utiliser ''git status'' pour voir les fichiers qui ont besoin d'être résolus # - après l'avoir corrigée dans votre éditeur, "git add filename" pour chacun des fichiers corrigés git rebase --continue git log -n5 --decorate --pretty=oneline # Vérifiez que les 5 dernières entrées du journal commencent maintenant par : # * (HEAD, bug/1234) votre modification # * (review/john/700) la dépendance # * (gerrit/master) git push gerrit HEAD:refs/for/master # ou git review
git push gerrit HEAD:refs/for/master%topic=myawesometopic
ou
git review -t myawesometopic
Dépendances inter projets
Vous pouvez également utiliser des dépendances inter projets (par exemple une extension nécessitant un changement de noyau avant d'être fusionnée).
Vous pouvez y parvenir en ajoutant par exemple Depends-On: I75b266da99e7dcb948f10d182e7f00bb3debfac6 dans le pied de page d'un message de commit.
Utiliser l'identifiant complet de modification ('I' + 40 caractères).
Voir https://docs.openstack.org/infra/zuul/feature/zuulv3/user/gating.html#cross-project-dependencies pour d'autres détails.
Exemples : Gerrit:539718, Gerrit:534888
Segmenter une validation en validations plus petites
Expliqué en détails sur Segmenter une modification soumise.
Supprimer votre branche locale après avoir soumis vos modifications dans Gerrit
you@yourmachine:~/puppet (production)$ git checkout -b mycoolfeature
you@yourmachine:~/puppet (mycoolfeature)$ vi foobar
you@yourmachine:~/puppet (mycoolfeature)$ git commit -a -m "Committing my cool feature"
you@yourmachine:~/puppet (mycoolfeature)$ git review -f
you@yourmachine:~/puppet (production)$
Si le drapeau -f est passé à git-review, il tentera de soumettre la modification, et s'il y parvient, il reviendra sur la branche principale (de production, dans ce cas) et supprimera la branche de fonctionnalité.
Fusionner un sous-module dans un projet parent
Voir Sous-module merge.
Utiliser un bac à sable personnel pour vos propres branches
Gerrit permet la création de bacs à sable personnels où les utilisateurs peuvent mettre en attente le code sur lequel ils travaillent dans une branche personnelle qui ne nécessite pas l'intervention de l'administrateur pour pousser. Voir le Bac à sable personnel.
Dépannage
Pour les problèmes et la manière de les résoudre, voir le Dépannage.
Travailler sur un ensemble existant de corrections
Parfois, vous voulez travailler sur un ensemble de changements initié par quelqu'un d'autre et ensuite téléverser vos changements comme un nouvel ensemble de correctifs.
# Notez dans l'URL gerrit le numéro de référence de l'ensemble des modifications,
# par exemple, https://gerrit.wikimedia.org/r/#/c/70112/, ainsi 70112
# Dans votre copie locale de la branche ''master'', copiez l'ensemble des modifications
# et passer à cette branche avec la commande suivante.
git review -d 70112
# Faites les modifications nécessaires et validez-les en tant qu'amendement,
# en ajoutant des commentaires appropriés dans le message de validation.
git commit --all --amend
# Poussez la configuration du patch sur Gerrit comme d'habitude.
git review -R
# Les autres développeurs peuvent ensuite mettre à jour leur copie locale de l'ensemble de corrections
# avec la commande suivante.
git review -d 70112
-m pour spécifier un résumé de validation : cela va remplacer le résumé précédent et regénérer l'identifiant de modification. Au lieu de cela, utilisez votre éditeur de texte pour modifier le résumé de validation si nécessaire, et gardez intacte la ligne comportant l'identifiant de la modification. (Voir : Amender une modification)
rebase manuel (sur une branche)
Parfois, le bouton rebase dans l'interface utilisateur Gerrit est incapable de rebaser automatiquement les modifications sur la branche de travail et vous devez effectuer le rebase sur la ligne de commande :
# Télécharger d'abord l'ensemble actuel des corrections
$ git-review -d 424242
# Ensuite, assurez-vous d'avoir une copie à jour de la branche cible ("main" dans ce cas)
$ git fetch origin main
# Puis faites un rebase de vos corrections et corrigez les conflits pouvant apparaître
$ git rebase -i origin/main
rebase manuel (sur le parent)
Parfois, le bouton rebase dans l'interface utilisateur Gerrit est incapable de rebaser automatiquement une modification dans un ensemble de modifications placé sur son parent et vous devez effectuer le changement à partir de la ligne de commande.
$ PARENT=424242
$ CHILD=424243
# Récupérez d'abord une référence sur le dernier PS dans la modification parente et extrayez-la.
# Vous pouvez obtenir le lien de l'interface utilisateur de Gerrit : dans le menu ''More'', sélectionnez ''Download patch'' pour télécharger le patch et utilisez le lien ''Checkout'', par exemple
$ git fetch "https://gerrit.wikimedia.org/r/operations/puppet" refs/changes/$i/${PARENT}/${PS} && git checkout FETCH_HEAD
# sauvegarder ce point dans sa propre branche
$ git branch merge_${PARENT}
# extraire les modifications fille
$ git-review -d ${CHILD}
# rebase sur la branche créée précédemment
$ git rebase -i merge_${PARENT}
# téléversez les corrections
$ git-review
Relecture de code
Relire et commenter le code
La fonctionnalité de base est expliquée dans le Tutoriel Git et Gerrit.
Quelques bits supplémentaires :
- Diff Against menu déroulant. Ce menu vous permettra de modifier les modifications que vous relisez. Ceci est utile si vous avez relu un ancien ensemble de modifications et que vous voulez vous assurer qu'ils ont été pris en compte. Au lieu de lire les diff de l'ensemble des modicfications de la validation de base, vous pouvez lire seulement les différences entre les modifications actuelles et les modifications que vous avez relues. Il y a aussi un bonus : vous pouvez voir vos commentaires sur le côté gauche. S'il y a eu une validation avec rebase, les diffs affichent divers éléments obsolètes, mais vous pourrez toujours lire les modifications une par une et ce sera plus rapide.
- Open All bouton :
- Ouvre les diff(s) dans un nouvel onglet. Vous pouvez double cliquer sur une ligne et la commenter, puis enregistrer un commentaire du brouillon ! Ensuite, cliquez sur Up to change pour revenir à l'ensemble des modifications.
- Pour les validations contenant des espaces blancs (comme l'indentation d'un bloc modifié), il est préférable de définir les préférence du diff de manière appropriée pour faciliter la relecture. Lors de l'affichage d'un diff, il y a un lien Préférences en haut. Puis il y a deux paramètres importants à considérer. Ignore Whitespace et Intraline Difference. Le dernier (Intraline Difference) est particulièrement utile si un bloc de code est indenté car ce paramètre va afficher les tabulations ajoutées ce qui permet aux autres modifications d'être reconnues sans que vous ayiez à comparer mot à mot (voir la capture d'écran).
Comment commenter, relire, et fusionner le code dans Eclipse
Une alternative à l'interface web de Gerrit est la relecture de code à partir de Eclipse en utilisant l'environnement de gestion des tâches Mylyn.
Pour commencer, télécharger et installer Eclipse, puis Mylyn à partir du menu Installer un nouveau logiciel (depuis le 5 octobre 2013 vous avez besoin du site de mise à jour des instantanés pour utiliser l'installation de Gerrit Wikimedia).
Quand vous exécuterez ensuite Eclipse, on vous demandera d'ajouter une tâche pour Mylyn.
De là, vous devrez installer le connecteur pour Gerrit, spécifiez https://gerrit.wikimedia.org/r/ comme étant l'URL du serveur, et ajouter votre nom d'utilisateur et votre mot de passe.
Comment relire et fusionner le code via la ligne de commande
En utilisant dippy-bird vous pouvez facilement faire la relecture en mode ligne de commande ainsi que la fusion. Le paramètre de requête est la modification que vous voulez traiter.
php dippy-bird.php --username=USERNAME --server=gerrit.wikimedia.org --port=29418 --action=submit --query=12345
Vous pouvez donc l'utiliser pour approuver une série de validations :
#!/bin/bash
for i in {51541..51545}
do
php dippy-bird.php --username=USERNAME --server=gerrit.wikimedia.org --port=29418 --action=submit --query=$i
done
Approbation en masse des modifications sur les dépôts
Nous pourrions parfois avoir à générer une tonne de modifications, par exemple lorsque nous faisons la même modification sur tous nos dépôts.
Dans le passé, cela s'est produit après que les extensions MediaWiki aient été migrées vers Git puisque nous devions ajouter un fichier .gitreview dans chaque dépôt.
D'abord, vous pouvez interroger Gerrit pour une liste de modifications en utilisant le CLI ! Un alias utile :
alias gerrit='ssh -p 29418 gerrit.wikimedia.org gerrit'
Puis, utilisez cela pour exécuter une requête telle que toutes les modifications ouvertes sur le sujet dotgitreview :
gerrit query 'status:open topic:dotgitreview'
Avec quelques tours magiques dans le shell, vous pouvez obtenir une liste de numéros de modifications :
gerrit query 'status:open topic:dotgitreview' \ | egrep '^ number' | cut -d\ -f4- > CHANGES_NUMBERS
Puis bouclez sur l'ensemble et approuvez les modifications à distance :
for i in `cat CHANGES_NUMBERS`; do gerrit review --verified=+1 --code-review=+2 --submit "$i,1"; done
Dépannage
Pour les problèmes et la manière de les résoudre voir Dépanner dans Gerrit.
Comment créer un dépôt (Gerrit project)
Voir Demander un nouveau dépôt Git. Un formulaire est à remplir. Il doit être traité très rapidement (quelques jours).
Autres conseils
Tableau de bord du projet Gerrit
Voir aussi Documentation sur les tableaux de bord des utilisateurs.
Chaque dépôt référentiel Gerrit possède un ou plusieurs tableaux de bord qui peuvent être personnalisés.
Le tableau de bord par défaut est affiché lorsque vous cliquez sur un lien de projet n'importe où dans Gerrit.
Par exemple, en cliquant sur mediawiki/core sur une page de validation liée au noyau MediaWiki, vous irez sur https://gerrit.wikimedia.org/r/q/project:mediawiki%252Fcore.
Dans Gerrit, les tableaux de bord sont créés dans les groupes.
Chaque dépôt hérite du groupe de tableaux de bord par défaut du projet méta All-Projects.
Le tableau de bord d'un projet est défini par défaut à default:recent.
Vous pouvez modifier le tableau de bord utilisé par défaut dans le fichier project.config, dans la branche refs/meta/config d'un dépot.
Les instructions détaillées se trouvent ci-dessous.
Voir Module:Gerrit dashboard pour plus d'informations.
Il est recommandé d'ajouter les alias suivants à votre fichier .gitconfig.
Voir les alias Git pour plus d'informations.
[alias]
dashboards-checkout = "!f() { git fetch origin refs/meta/dashboards/teams:refs/meta/dashboards/teams && git checkout -B meta/dashboards/teams refs/meta/dashboards/teams; }; f"
dashboards-review = "!f() { git push origin HEAD:refs/for/refs/meta/dashboards/teams; }; f"
dash-co = dashboards-checkout
dash-review = dashboards-review
Gérer un tableau de bord d'équipe
- Pour les équipes Wikimedia, nous utilisons le dépôt parent
wikimediapour héberger leur tableau de bord.- Voir tableaux de bord Gerrit des équipes pour les exemples.
- Voir Dashboards/teams sur meta pour le code source (ouvrir ces fichiers pour avoir des exemples du format de fichier et des requêtes).
- Voir le Tableau de bord de la revue de code sur Gerrit.
- Clonez le dépôt si ce n'est pas déjà fait,
git clone ssh://<gerrit-username>@gerrit.wikimedia.org:29418/wikimedia. - Extraire la branche
git dash-codes tableaux de bord de l'équipe - Créer (ou modifier) le fichier de configuration du tableau de bord pour votre équipe (en minuscules avec des tirets facultatifs, sans extension de fichier). Voir aussi la Documentation Gerrit.
- Stockez vos modifications (stage) et faites une validation locale.
- Pousser la validation pour relecture
git dash-review. Vous pouvez généralement les fusionner vous-même, mais vous pouvez aussi proposer les modifications à d'autres personnes pour qu'elles les examinent si vous le préférez.
Allez aux Tableaux de bord de l'équipe Gerrit et cliquez sur votre tableau de bord. Ou utiliser le motif d'URL suivant :
https://gerrit.wikimedia.org/r/p/wikimedia/+/dashboard/teams:my-file-name
Un mauvais paramètre ou une erreur de syntaxe apparaissent comme une erreur 404 sur le tableau de bord correspondant. Les fichiers peuvent être validés avec :
git config -f FILE --list
Ajoutez ceci à votre menu dans Gerrit pour un accès facile :
- Revoyez vos paramètres Gerrit
- Aller à la section Menu de vos paramètres.
- Ajoutez l'URL
/p/wikimedia/+/dashboard/teams:myteam(par exemple) avec une étiquette qui a un sens pour vous, comme « Mon équipe » - Considérez également l'ajout de https://gerrit.wikimedia.org/r/admin/repos/wikimedia,dashboards comme All Teams pour accéder facilement aux autres tableaux de bord.
- Cliquer sur Enregistrer les modifications et recharger l'onglet du navigateur.
Bookmarklet pour masquer les commentaires jenkins-bot
Exécuter ce JavaScript pour masquer tous les commentaires de jenkins-bot.
Particuliérement adapté à Masquer les commentaires marqués quand vous devez vous assurer que tous les commentaires humains ont été répondus.
Prefixer avec javascript: pour ajouter un bookmarklet[1].
Array.from(document.querySelectorAll('[class*=messageBox]')).filter(box => box.querySelector('[class*=name]').textContent === 'jenkins-bot').forEach(box => box.style.display = 'none')
Liens pour la relecture de code
Les liens vers les anciennes révisions de SVN Code Review sont stockés dans les notes des commits. Ils peuvent être récupérés pour affichage dans le journal de git en utilisant la commande suivante :
git fetch origin refs/notes/commits:refs/notes/commits
Noter que cela doit être fait séparément pour chaque dépôt git.
Scores pour la relecture Gerrit
Comme ci-dessus les métadonnées de la relecture de code sont stockées dans les notes de validation et peuvent être récupérées en utilisant :
git fetch gerrit refs/notes/review:refs/notes/review
Pour les récupérer régulièrement, ajouter à votre configuration git.
Pour les afficher dans git log (les syntaxes similaires fonctionnent aussi pour les outils connexes) :
git log --notes=review
Proxy ssh pour gerrit
Si Gerrit est lent au téléversement des correctifs, cela pourrait être dû un problème de réseau. (surtout si vous êtes en Europe, à certaines heures de la journée) Si vous avez un serveur ou une machine virtuelle aux États-Unis ou un autre proxy que vous pouvez utiliser, alors vous pouvez accéder à Gerrit de cette façon.
Dans votre ~/.ssh/config ajoutez quelquechose comme :
Host gerrit.wikimedia.org
User aude
Port 29418
Hostname gerrit.wikimedia.org
IdentityFile=~/.ssh/gerrit
ProxyCommand nc -x 127.0.0.1:8081 %h %p
Puis connectez-vous au proxy (par exemple via ssh, avec l'option -D 8081). Ensuite, l'accès à Gerrit doit fonctionner pour téléverser et télécharger les correctifs et même plus rapidement.
Lier les URLs Gerrit à partir des wikis Wikimedia en utilisant la syntaxe des liens internes
Pour référencer la révision 1234 de Gerrit utiliser [[gerrit:1234|revision 1234]] : révision 1234.
Modifier l'utilisateur associé à un commit
Gerrit n'accepte que les corrections validées à l'aide de votre adresse courriel enregistrée. Si vous avez plusieurs adresses courriel avec lesquelles vous avez fait vos commit (par exemple, si vous avez des paramètres git au travail et d'autres à la maison que vous voulez garder distincts), vous devez mettre à jour localement l'adresse sous laquelle vous validez lorsque vous copiez un dépôt.
git config user.email me@example.org
Cependant, si vous oubliez de le faire après avoir extrait et validé, vous devrez mettre à jour votre adresse e-mail configurée et ensuite corriger cette validation ainsi :
git commit --amend --no-edit --reset-author
Si vous voulez éviter de vous en souvenir, vous pouvez faire ceci dans votre .gitconfig :
[includeIf "gitdir:~/src/mediawiki/"]
path = ~/.gitconfig-mediawiki
...puis créer un .gitconfig-mediawiki :
# Tout ce qui est entré ici ne sera chargé dans le dépôt d'où il sera extrait
# ~/src/mediawiki/
[user]
email = me@example.org
Vous pouvez ajouter toute autre commande spécifique au développement de Mediawiki que vous voulez.
Tant que vous consultez quelque chose lié à Mediawiki dans le répertoire ~/src/mediawiki, ce fichier de configuration sera chargé et remplacera le gitconfig de votre base.
Voir aussi
- Conseils Git
- Segmenter les modifications soumises
- Projets suivis
- Gerrit flux de travail ops
- Toutes les pages de Git/ et Gerrit/
- Sélection des liens externes du tutoriel Git et Gerrit.
Notes
- ↑ bookmarklets — signet du navigateur qui exécute du code JavaScript au lieu d'ouvrir une page web.