[JAVA] Contribué à Gradle et a été nommé dans la note de publication

Aperçu

Cette fois, il a contribué à Gradle et a été nommé dans la note de publication. Je suis tellement heureux! Cependant, ce n'est pas vraiment une histoire passionnante. Le contenu de la correction est sobre, et j'expliquerai les détails plus tard, mais j'ai causé beaucoup de problèmes en faisant diverses choses ... Même si cela fonctionne comme ça, je suis reconnaissant à tous les développeurs Gradle qui me traitent comme un contributeur.

Eh bien, la forme a été une expérience précieuse pour moi de toute façon, donc je la posterai en gardant un enregistrement du processus du déclencheur à la fusion.

La note de publication pertinente est ici. https://docs.gradle.org/6.6/release-notes.html

Qu'est-ce que tu as fait

J'ai modifié le contenu XML des résultats de test qui sont générés lorsque j'exécute un test écrit dans JUnit 5 sur Gradle. Plus précisément, si l'annotation «@ DisplayName» est ajoutée, la valeur est sortie au format XML. @ DisplayName est une annotation introduite dans JUnit 5 qui définit le nom affiché dans les résultats d'exécution de test pour les classes de test et les méthodes de test. Je l'utilise comme ça.

@DisplayName("Test de classe de calcul")
class CalcTest {
    @Test
    @DisplayName("add méthode passe 2 et 3 et retourne 5")
    void testAdd() {
        var calc = new Calc();
        assertEquals(5, calc.add(2, 3));
    }
}
Screen Shot 2020-07-25 at 20.35.44.png

Comme il n'existait pas de fonction de ce type jusqu'à JUnit4, le nom de la méthode de test était affiché en tant que nom du test dans le résultat de l'exécution du test. Certaines personnes ont écrit le nom de la méthode de test en japonais pour rendre le nom du test plus facile à comprendre. Vous pouvez utiliser @ DisplayName pour définir le nom du test séparément du nom de la méthode de test, et le résultat de l'exécution du test affichera le nom spécifié par @ DisplayName au lieu du nom de la méthode. Cela évite le fait d'écrire le nom de la méthode en japonais, ce que certaines personnes hésitent à faire.

Je voudrais dire que l'outil qui génère le résultat du test peut ne pas prendre en charge @ DisplayName, auquel cas la valeur définie dans @ DisplayName est ignorée et le nom de la méthode est affiché. Je vais finir. Gradle ne prend pas entièrement en charge «@ DisplayName» [^ gradle_displayname], et pour le fichier XML du résultat du test, la valeur de «@ DisplayName» est ignorée et le nom de la classe de test et le nom de la méthode sont affichés. Parce que c'était, il est venu à cette correction. [^ gradle_displayname]: Le fichier HTML qui affiche les résultats du test a été adressé avant que je ne le touche.

Le progrès

Déclencheur

(Comme c'était il y a longtemps, il y a certaines parties où la mémoire est ambiguë et les détails peuvent différer de ceux réels.)

Notre équipe utilise JUnit 4 depuis longtemps, mais lorsque nous avons proposé de passer à JUnit 5, cela a été facilement accepté. Cependant, pour ce faire, il est bien sûr nécessaire que tout le monde dans l'équipe puisse utiliser JUnit 5, nous avons donc organisé facilement une session d'étude JUnit 5 au sein de l'équipe. Dans la session d'étude, j'ai mentionné le @ DisplayName et j'ai dit que je devrais définir @ DisplayName autant que possible grandement </ s>. Je pense que c'était peu de temps après, mais l'un des membres de l'équipe a souligné que la valeur de réglage de @ DisplayName n'était pas reflétée sur l'écran d'affichage du résultat du test de Jenkins. Quand je l'ai vérifié, c'était vrai. C'était juste après que j'ai appelé pour utiliser @ DisplayName, donc c'était un peu moche ...

Recherche de cause

Jenkins lit le fichier XML des résultats du test et affiche l'écran des résultats du test, mais je le savais depuis le début, alors j'ai d'abord regardé le contenu du fichier XML. En conséquence, le nom de la classe et le nom de la méthode ont été affichés en XML au lieu de la valeur de @ DisplayName. La cause n'est probablement pas Jenkins, mais l'outil qui a généré le fichier XML. Je ne me souviens pas comment je l'ai compris, mais j'ai trouvé que c'était Gradle qui avait généré le XML. En d'autres termes, c'était parce que Gradle ne supportait pas «@ DisplayName».

J'essaye de cloner en quelque sorte

Ignorer la valeur de @ DisplayName n'a pas beaucoup d'effet, mais j'étais curieux à ce sujet, alors j'ai cloné la source Gradle. Lorsque j'ai recherché par le nom de l'élément ou le nom de l'attribut XML, un seul endroit a été atteint. En d'autres termes, c'était exactement le code qui effectuait le traitement de sortie XML. Je l'ai lu brièvement, et je peux le faire avec ce genre de correction, non? J'ai décidé de l'essayer. Dans le passé, j'ai contribué à Jenkins avec seulement des modifications très mineures de la documentation, donc l'obstacle mental peut avoir été un peu réduit. Récit de participation à l'atelier OSS Gate Tokyo 2019-12-14 et contribution à Jenkins

Découvrez comment contribuer

Vérifiez s'il s'agit d'OSS

Pour contribuer à OSS, vous devez d'abord vous assurer que la cible est vraiment OSS. S'il n'y avait pas d'OSS, il n'y aurait pas de contribution ... Vous pouvez savoir s'il s'agit d'OSS en vérifiant la licence. Comme je l'ai écrit dans l'article ci-dessus (ou plutôt, j'ai écrit ceci en regardant l'article ci-dessus), si la licence est dans la liste ci-dessous, on peut dire qu'il s'agit d'OSS. https://opensource.org/licenses/alphabetical Et la licence est généralement écrite sur le site officiel ou GitHub.

La licence de Gradle est la licence Apache 2.0. https://github.com/gradle/gradle/blob/master/LICENSE

Depuis Apache License 2.0 est sur la liste, Gradle peut être considéré comme OSS.

Enquête sur la façon de contribuer à la demande d'extraction Gradle-First

La manière dont vous contribuez à un OSS est différente pour chaque OSS. La plupart du temps, il existe un document qui décrit comment contribuer, alors cherchez-le. Il y avait le document suivant à propos de Gradle, alors j'ai procédé selon lui. https://github.com/gradle/gradle/blob/master/CONTRIBUTING.md

Bien sûr, tout est en anglais, donc j'ai mis du temps à lire ... Normalement, le problème est ouvert en premier, mais le problème dans ce cas était déjà ouvert par une autre personne. https://github.com/gradle/gradle/issues/11445

Ensuite, j'ai pensé que je devrais lancer une pull request sous la forme d'une correction à cela. Cela semblait facile à corriger et la quantité de correction était faible, alors j'ai pensé qu'il serait acceptable de lancer une demande de tirage soudainement. C'était la même chose avec Jenkins. (Eh bien, je me rendrai compte plus tard que la perception était trop douce ...)

J'ai fait des corrections, ajouté UT, vérifié l'opération, écrit une phrase en anglais traçable tout en m'appuyant sur l'outil de traduction et lancé la première demande d'extraction avec enthousiasme.

Il y a une réaction

Cela fait un moment que j'ai lancé la pull request, mais il y a eu une réaction. Selon lui, le test a échoué en raison de l'effet de la correction ... J'étais sûr que le test du projet contenant la source modifiée réussirait, mais le test d'un autre projet échouait. Je ne l'ai pas remarqué du tout ... C'est l'une des grandes réflexions. Dans le correctif que j'ai fait, le résultat lorsque @ DisplayName n'était pas donné était différent d'avant le correctif. Plus précisément, le nom de la classe était FQN avant la modification, mais après la modification, le nom de la classe n'incluait pas le nom du package. J'ai vérifié l'opération, mais je ne l'ai pas remarqué car il n'y avait pas de différence avant et après la modification car je l'ai vérifiée avec la classe du package par défaut. C'est une histoire très embarrassante ...

Ré-correction

En réponse à l'indication, nous avons examiné comment y remédier. Pour résoudre ce problème, vous devez déterminer si «@ DisplayName» est donné. Au début, je pensais que ce ne serait pas si grave, mais cela s'est avéré assez difficile. Il devrait y avoir du code qui récupère la valeur de @ DisplayName quelque part, mais il est plus large que prévu et il m'a fallu beaucoup de temps pour comprendre où se trouvait ce code. De plus, il est nécessaire de transmettre la valeur du code correspondant à la première partie corrigée, mais au cours du processus, un nombre considérable de fichiers sera corrigé et, par conséquent, UT échoue également ici et là, et c'est assez difficile. fait. Nous avons également connu de nombreux autres types d'erreurs d'exécution. J'étais un peu regretté d'avoir lancé une pull request, disant que j'étais coincé dans un problème plus grave que prévu, mais à la fin j'ai réussi à le faire fonctionner.

Je ne savais pas quoi faire si je le corrigeais à nouveau après avoir lancé une pull request, mais quand je l'ai googlé, cela a été utile car ces informations sont sorties en haut. https://teratail.com/questions/122843

Lorsque j'ai corrigé la demande de tirage, il y a eu une réaction immédiate. J'ai reçu quelques indications, mais j'ai été heureux de recevoir un commentaire (probablement) à l'effet que le sens de la correction n'était pas faux. Pour le moment, il me semblait que je devais simplement supprimer la partie signalée, alors je l'ai fait.

Demander un réexamen

Après la correction ci-dessus, j'ai pu obtenir une critique très rapidement, mais cette fois je n'ai pas pu obtenir de commentaire sur la critique. Je me demandais pourquoi, mais apparemment, c'était parce que je n'avais pas demandé de révision ... Depuis que j'ai écrit un commentaire indiquant qu'il a été corrigé, j'ai eu envie de demander un examen, mais apparemment j'ai dû soumettre une demande de révision selon le mécanisme de GitHub. Il semble que vous puissiez soumettre une demande de révision en cliquant sur le point à droite du nom du réviseur, alors je l'ai fait.

Correction par le réviseur pour fusionner

J'ai obtenu une réponse assez rapidement après avoir demandé un examen, mais la demande d'extraction que j'ai lancée a été fermée, une nouvelle demande d'extraction a été créée et le réviseur a corrigé à nouveau mon code modifié. Après cela, il a été fusionné. Est-il courant que les réviseurs modifient directement le code du réviseur? Eh bien, si vous y pensez normalement, ce n'est pas au moins un plaisir. Je me demande si c'était comme un ken de laisser ça à ce type ... Être réparé signifie qu'il y a un problème, alors je pensais que je manquais toujours de capacités.

Eh bien, j'étais très heureux que le code que j'ai écrit ait été fusionné, même s'il a été corrigé. De plus, à un moment donné, j'ai été un peu regretté d'avoir lancé la demande de tirage, alors j'avais le sentiment fort que mes épaules étaient déchargées et j'ai été libéré parce que j'ai réussi à la terminer jusqu'au bout.

Résumé des points de réflexion

  • Confirmation insuffisante du fonctionnement après correction
  • Du coup, j'ai mal compris le niveau de difficulté de correction (je peux dire que j'ai pu contribuer à cause de ça ... w)
  • Je n'ai pas remarqué que le test échouait
  • J'ai fait attendre le critique en vain sans demander un avis (je ne savais pas comment cela fonctionne. Recherches insuffisantes)
  • Je ne l'ai pas écrit ci-dessus, mais quand j'y ai pensé, je n'ai pas fait de branche de correction.

Ce n'est pas un point de réflexion, mais je n'ai pas peur du manque de puissance, alors j'aimerais étudier en regardant les différences corrigées. (J'ai l'impression que je devrais le faire rapidement ...)

À la fin

En fait, je voulais écrire un article du genre "Ce n'est pas difficile de contribuer à OSS! Faisons-le pour tout le monde!", Mais quand je l'ai essayé, c'était assez difficile ... Cela peut être facile)

Pour le moment, j'ai pu acquérir cette fois l'expérience de la «contribution à l'OSS», alors j'ai pensé que je pourrais travailler avec une certaine confiance lorsque la même chose se reproduira à l'avenir. Cela a été corrigé! </ s>

À l'avenir, je ne pense pas que je rechercherai activement des contributions, mais si je trouve un problème avec l'OSS que j'utilise habituellement, je pense que je devrais simplement vérifier si c'est un problème que je peux résoudre moi-même. pense.

prime

C'est beaucoup de contenu embarrassant, mais je vais exposer la pull request pertinente. https://github.com/gradle/gradle/pull/12541

Recommended Posts