Jump to content

Gerrit/Utilisation avancée

From mediawiki.org
This page is a translated version of the page Gerrit/Advanced usage and the translation is 97% complete.
Outdated translations are marked like this.
Flux de travail du développement de MediaWiki

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 -s ajoute un gerrit distant à 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.

Utilisez la branche qui correspond à votre numéro de modification.
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 push compliqué à la place de git 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 faites git checkout -b random-new-topic-name suivi du git review -R habituel (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-name fonctionne également si vous voulez pousser sur une branche distante à partir d'une branche de relecture.

Donne :

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.

Avertissement Avertissement : 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
Si vous souhaitez initialiser un sujet, utilisez :
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
N'UTILISEZ PAS le drapeau -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

Revue de 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.

Interface diff / commentaire dans Eclipse


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.

Vous pouvez décider de gérer votre tableau de bord sur le wiki au lieu d'utiliser un dépôt Git.
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

  1. Pour les équipes Wikimedia, nous utilisons le dépôt parent wikimedia pour héberger leur tableau de bord.
  2. Clonez le dépôt si ce n'est pas déjà fait, git clone ssh://<gerrit-username>@gerrit.wikimedia.org:29418/wikimedia.
  3. Extraire la branche git dash-co des tableaux de bord de l'équipe
  4. 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.
  5. Stockez vos modifications (stage) et faites une validation locale.
  6. 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

Ajouter un tableau de bord d'équipe à votre menu

Ajoutez ceci à votre menu dans Gerrit pour un accès facile :

  1. Revoyez vos paramètres Gerrit
  2. Aller à la section Menu de vos paramètres.
  3. Ajoutez l'URL /p/wikimedia/+/dashboard/teams:myteam (par exemple) avec une étiquette qui a un sens pour vous, comme « Mon équipe »
  4. 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.
  5. 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$ref.[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

Notes

  1. bookmarklets — signet du navigateur qui exécute du code JavaScript au lieu d'ouvrir une page web.