[JAVA] Hat zu Gradle beigetragen und wurde im Release Note genannt

Überblick

Dieses Mal trug er zu Gradle bei und wurde im Release Note genannt. Ich bin so glücklich! Es ist jedoch keine wirklich aufregende Geschichte. Der Inhalt der Korrektur ist nüchtern, und ich werde die Details später erklären, aber ich habe viel Ärger verursacht, indem ich verschiedene Dinge getan habe ... Auch wenn es so funktioniert, bin ich allen Gradle-Entwicklern dankbar, die mich als Mitwirkenden behandeln.

Nun, die Form war sowieso eine wertvolle Erfahrung für mich, daher werde ich sie veröffentlichen, indem ich den Prozess vom Auslöser bis zur Zusammenführung aufzeichne.

Der entsprechende Versionshinweis ist hier. https://docs.gradle.org/6.6/release-notes.html

Was hast du getan

Ich habe den XML-Inhalt der Testergebnisse optimiert, die ausgegeben werden, wenn ich einen in JUnit 5 auf Gradle geschriebenen Test ausführe. Insbesondere wenn die Annotation "@ DisplayName" hinzugefügt wird, wird der Wert in XML ausgegeben. @ DisplayName ist eine in JUnit 5 eingeführte Anmerkung, die den Namen festlegt, der in den Testausführungsergebnissen für Testklassen und Testmethoden angezeigt wird. Ich benutze es so.

@DisplayName("Klassentest berechnen")
class CalcTest {
    @Test
    @DisplayName("Die Methode add übergibt 2 und 3 und gibt 5 zurück")
    void testAdd() {
        var calc = new Calc();
        assertEquals(5, calc.add(2, 3));
    }
}
Screen Shot 2020-07-25 at 20.35.44.png

Da es bis JUnit4 keine solche Funktion gab, wurde der Name der Testmethode als Testname im Ergebnis der Testausführung ausgegeben. Einige Leute haben den Namen der Testmethode auf Japanisch geschrieben, um das Verständnis des Testnamens zu erleichtern. Sie können @ DisplayName verwenden, um den Testnamen getrennt vom Namen der Testmethode festzulegen. Das Ergebnis der Testausführung zeigt den durch @ DisplayName angegebenen Namen anstelle des Methodennamens an. Dies vermeidet das Schreiben des Methodennamens auf Japanisch, was einige Leute nur ungern tun.

Ich möchte sagen, dass das Tool, das das Testergebnis ausgibt, möglicherweise nicht "@ DisplayName" unterstützt. In diesem Fall wird der in "@ DisplayName" festgelegte Wert ignoriert und der Methodenname angezeigt. Ich werde am Ende. Gradle unterstützt @ DisplayName [^ gradle_displayname] nicht vollständig, und für die XML-Datei des Testergebnisses wird der Wert von @ DisplayName ignoriert und der Name der Testklasse und der Methodenname werden ausgegeben. Weil es so war, kam es zu dieser Korrektur. [^ gradle_displayname]: Die HTML-Datei, in der die Testergebnisse angezeigt werden, wurde angesprochen, bevor ich sie berührt habe.

Fortschritt

Auslösen

(Da es lange her ist, gibt es einige Teile, in denen der Speicher mehrdeutig ist und die Details von den tatsächlichen abweichen können.)

Unser Team verwendet JUnit 4 schon lange, aber als wir vorschlugen, auf JUnit 5 umzusteigen, wurde dies problemlos akzeptiert. Dazu ist es jedoch natürlich erforderlich, dass jeder im Team JUnit 5 verwenden kann. Daher haben wir problemlos eine JUnit 5-Lernsitzung im Team durchgeführt. In der Lernsitzung erwähnte ich den "@ DisplayName" und sagte, dass ich "@ DisplayName" so weit wie möglich stark </ s> setzen sollte. Ich denke, es war kurz danach, aber eines der Teammitglieder wies darauf hin, dass der Einstellwert von "@ DisplayName" nicht auf dem Bildschirm des Testergebnisses von Jenkins angezeigt wurde. Als ich es überprüfte, war es wahr. Dies war direkt nachdem ich angerufen hatte, um "@ DisplayName" zu verwenden, also fühlte es sich ein bisschen hässlich an ...

Ursachenforschung

Jenkins liest die XML-Datei mit den Testergebnissen und zeigt den Bildschirm mit den Testergebnissen an, aber das wusste ich von Anfang an, also habe ich mir zuerst den Inhalt der XML-Datei angesehen. Infolgedessen wurden der Klassenname und der Methodenname anstelle des Werts "@ DisplayName" in XML ausgegeben. Die Ursache ist wahrscheinlich nicht Jenkins, sondern das Tool, das die XML-Datei generiert hat. Ich erinnere mich nicht, wie ich es herausgefunden habe, aber ich fand, dass Gradle das XML generiert hat. Mit anderen Worten, weil Gradle @ DisplayName nicht unterstützte.

Ich versuche irgendwie zu klonen

Das Ignorieren des Werts von "@ DisplayName" hat keine großen Auswirkungen, aber ich war neugierig und habe die Gradle-Quelle geklont. Bei der Suche nach dem Element- oder Attributnamen von XML wurde nur eine Stelle getroffen. Mit anderen Worten, das war genau der Code, der die XML-Ausgabeverarbeitung durchgeführt hat. Ich habe es kurz gelesen und kann es mit dieser Art von Korrektur machen, oder? Ich habe beschlossen, es zu versuchen. In der Vergangenheit habe ich mit nur geringfügigen Dokumentationsänderungen zu Jenkins beigetragen, sodass die mentale Hürde möglicherweise etwas gesenkt wurde. Geschichte der Teilnahme am OSS Gate Tokyo Workshop 2019-12-14 und des Beitrags zu Jenkins

Finden Sie heraus, wie Sie einen Beitrag leisten können

Überprüfen Sie, ob es sich um OSS handelt

Um zu OSS beizutragen, müssen Sie zunächst sicherstellen, dass das Ziel wirklich OSS ist. Ohne OSS gäbe es keinen Beitrag ... Sie können feststellen, ob es sich um OSS handelt, indem Sie die Lizenz überprüfen. Wie ich im obigen Artikel geschrieben habe (oder besser gesagt, ich habe dies geschrieben, während ich mir den obigen Artikel angesehen habe), kann gesagt werden, dass es sich um OSS handelt, wenn sich die Lizenz in der folgenden Liste befindet. https://opensource.org/licenses/alphabetical Und die Lizenz wird in der Regel auf der offiziellen Website oder auf GitHub geschrieben.

Gradles Lizenz ist Apache License 2.0. https://github.com/gradle/gradle/blob/master/LICENSE

Da Apache License 2.0 auf der Liste steht, kann Gradle als OSS bezeichnet werden.

Umfrage, wie Sie zur Gradle-First-Pull-Anfrage beitragen können

Die Art und Weise, wie Sie zu einem OSS beitragen, ist für jedes OSS unterschiedlich. Meistens gibt es ein Dokument, in dem beschrieben wird, wie Sie einen Beitrag leisten können. Suchen Sie also danach. Ich hatte das folgende Dokument über Gradle, also fuhr ich damit fort. https://github.com/gradle/gradle/blob/master/CONTRIBUTING.md

Natürlich ist alles auf Englisch, also habe ich lange gebraucht, um zu lesen ... Normalerweise wird das Problem zuerst geöffnet, aber das Problem wurde in diesem Fall bereits von einer anderen Person geöffnet. https://github.com/gradle/gradle/issues/11445

Dann dachte ich, ich sollte eine Pull-Anfrage in Form einer Korrektur dazu werfen. Es schien einfach zu beheben zu sein und der Umfang der Korrektur war gering, daher dachte ich, es wäre in Ordnung, plötzlich eine Pull-Anfrage zu stellen. Bei Jenkins war es genauso. (Nun, ich werde später feststellen, dass die Wahrnehmung zu süß war ...)

Ich nahm Korrekturen vor, fügte UT hinzu, überprüfte die Operation, schrieb einen nachvollziehbaren englischen Satz, während ich mich auf das Übersetzungstool stützte, und warf die erste Pull-Anfrage mit Aufregung.

Es gibt eine Reaktion

Es ist schon eine Weile her, dass ich die Pull-Anfrage gestellt habe, aber es gab eine Reaktion. Ihm zufolge scheiterte der Test an der Wirkung der Korrektur ... Ich war mir sicher, dass der Test für das Projekt mit der geänderten Quelle erfolgreich sein würde, aber der Test für ein anderes Projekt schlug fehl. Ich habe es überhaupt nicht bemerkt ... Es ist eine der großen Überlegungen. Bei der von mir vorgenommenen Änderung war das Ergebnis, wenn "@ DisplayName" nicht angegeben wurde, anders als vor der Änderung. Insbesondere war der Klassenname vor der Änderung FQN, aber nach der Änderung enthielt der Klassenname nicht den Paketnamen. Ich habe den Vorgang überprüft, ihn jedoch nicht bemerkt, da es vor und nach der Änderung keinen Unterschied gab, da ich ihn mit der Klasse des Standardpakets überprüft habe. Es ist eine sehr peinliche Geschichte ...

Neukorrektur

Als Reaktion auf die Indikation haben wir überlegt, wie wir das Problem beheben können. Um dies zu beheben, müssen Sie feststellen, ob "@ DisplayName" angegeben ist. Zuerst dachte ich, es wäre keine so große Sache, aber es stellte sich als ziemlich schwierig heraus. Es sollte irgendwo Code geben, der den Wert "@ DisplayName" erhält, aber er ist breiter als erwartet und es hat lange gedauert, bis ich herausgefunden habe, wo sich dieser Code befindet. Außerdem muss der Wert aus dem entsprechenden Code an den ersten korrigierten Teil übergeben werden. Dabei wird jedoch eine beträchtliche Anzahl von Dateien korrigiert. Infolgedessen schlägt UT auch hier und da fehl, und dies ist ziemlich schwierig. tat. Wir haben auch viele andere Arten von Laufzeitfehlern durchlaufen. Ich bedauerte ein wenig, dass ich eine Pull-Anfrage gestellt hatte und sagte, dass ich in einem ernsteren Problem steckte als erwartet, aber am Ende gelang es mir, es zum Laufen zu bringen.

Ich wusste nicht, was ich tun sollte, wenn ich es nach dem Auslösen einer Pull-Anfrage erneut korrigierte, aber als ich es googelte, war es hilfreich, da solche Informationen oben herauskamen. https://teratail.com/questions/122843

Als ich die Pull-Anfrage korrigierte, gab es eine sofortige Reaktion. Ich habe einige Hinweise erhalten, freute mich aber (wahrscheinlich) über einen Kommentar, dass die Richtung der Korrektur nicht falsch war. Vorläufig schien es, dass ich den hervorgehobenen Teil einfach löschen sollte, also tat ich es.

Fordern Sie eine erneute Überprüfung an

Nach der obigen Korrektur konnte ich sehr schnell eine Bewertung erhalten, aber diesmal konnte ich keinen Kommentar zur Bewertung erhalten. Ich habe mich gefragt warum, aber anscheinend war es, weil ich keine Bewertung angefordert habe ... Ich schrieb einen Kommentar dahingehend, dass er korrigiert wurde, also wollte ich eine Überprüfung anfordern, aber anscheinend musste ich eine Überprüfungsanforderung gemäß dem Mechanismus von GitHub einreichen. Es scheint, dass Sie eine Überprüfungsanfrage senden können, indem Sie auf den Punkt rechts neben dem Namen des Überprüfers klicken, also habe ich dies getan.

Korrektur durch Prüfer zum Zusammenführen

Nachdem ich eine Überprüfung angefordert hatte, erhielt ich ziemlich schnell eine Antwort, aber die von mir geworfene Pull-Anfrage wurde geschlossen, eine neue Pull-Anfrage wurde erstellt und der Prüfer korrigierte meinen geänderten Code erneut. Danach wurde es zusammengeführt. Ist es üblich, dass Prüfer den Code des Prüfers direkt ändern? Wenn Sie normal darüber nachdenken, ist es zumindest kein Vergnügen. Ich frage mich, ob es wie ein Ken war, es diesem Kerl zu überlassen ... Fixiert zu sein bedeutet, dass es ein Problem gibt, also dachte ich, dass mir immer noch die Fähigkeit fehlt.

Nun, ich war sehr froh, dass der von mir geschriebene Code zusammengeführt wurde, obwohl er behoben wurde. Außerdem hatte ich irgendwann ein wenig Bedauern darüber, dass ich die Pull-Anfrage gestellt hatte, sodass ich das starke Gefühl hatte, dass meine Schultern entladen waren und ich freigelassen wurde, weil ich es geschafft hatte, sie bis zum Ende zu beenden.

Zusammenfassung der Reflexionspunkte

  • Unzureichende Bestätigung des Betriebs nach der Korrektur
  • Infolgedessen habe ich den Schwierigkeitsgrad der Korrektur falsch verstanden (ich kann sagen, dass ich dadurch einen Beitrag leisten konnte ... w)
  • Ich habe nicht bemerkt, dass der Test fehlgeschlagen ist
  • Ich habe den Rezensenten vergeblich warten lassen, ohne eine Rezension anzufordern (ich wusste nicht, wie es funktioniert. Unzureichende Recherche)
  • Ich habe es oben nicht geschrieben, aber als ich darüber nachdachte, habe ich keinen Korrekturzweig erstellt.

Es ist kein Reflexionspunkt, aber ich habe das Gefühl, dass mir die Kraft fehlt, also werde ich lernen, indem ich die korrigierten Unterschiede betrachte. (Ich habe das Gefühl, ich sollte es schnell tun ...)

Am Ende

Eigentlich wollte ich einen Artikel schreiben wie "Es ist nicht schwer, zu OSS beizutragen! Lass es uns für alle tun!", Aber als ich es tatsächlich versuchte, war es ziemlich schwierig ... (Es liegt auch an meinen mangelnden Fähigkeiten und es ist in erster Linie eine Prise. Es kann einfach sein)

Vorläufig konnte ich diesmal die Erfahrung des "Beitrags zu OSS" sammeln, so dass ich dachte, ich könnte mit etwas Selbstvertrauen arbeiten, wenn das Gleiche in Zukunft wieder passiert. Es wurde behoben! </ s>

Ich glaube nicht, dass ich in Zukunft aktiv nach Beiträgen suchen werde, aber wenn ich ein Problem mit dem OSS finde, das ich normalerweise verwende, sollte ich einfach prüfen, ob es ein Problem ist, das ich selbst beheben kann. Überlegen.

Bonus

Es ist eine Menge peinlicher Inhalte, aber ich werde die relevante Pull-Anfrage offenlegen. https://github.com/gradle/gradle/pull/12541

Recommended Posts