[JAVA] Contributed to Gradle and was named in the release notes

Overview

This time, I contributed to Gradle and the name appeared in the release notes. I'm so happy! Actually, it's not a very exciting story. The content of the correction is sober, and I will explain the details later, but I have caused a lot of trouble by doing various things ... Even though it works like that, I'm just grateful to all the Gradle developers who treat me as a contributor.

Well, the shape was a valuable experience for me anyway, so I'll post it by keeping a record of the process from the trigger to the merge.

The relevant release notes are here. https://docs.gradle.org/6.6/release-notes.html

What did you do

I messed with the XML content of the test results output when running a test written in JUnit 5 with Gradle. Specifically, if the @DisplayName annotation is added, the value is output to XML. @DisplayName is an annotation introduced in JUnit 5 that sets the name displayed in the test execution result for a test class or test method. I use it like this.

@DisplayName("Computation class test")
class CalcTest {
    @Test
    @DisplayName("add method passes 2 and 3 and returns 5")
    void testAdd() {
        var calc = new Calc();
        assertEquals(5, calc.add(2, 3));
    }
}

Since there was no such function until JUnit4, the test method name was output as the test name in the test execution result. Some people wrote the test method name in Japanese to make the test name easier to understand. You can use @DisplayName to set the test name separately from the test method name, and the test execution result will display the name specified by @DisplayName instead of the method name. This avoids the act of writing the method name in Japanese, which some people are reluctant to do.

I would like to say that the tool that outputs the test result may not support @DisplayName, in which case the value set in @DisplayName is ignored and the method name is displayed. It will end up. Gradle does not fully support @DisplayName [^ gradle_displayname], and for the XML file of the test result, the value of @DisplayName is ignored and the test class name and method name are output. Because it was, it came to this correction. [^ gradle_displayname]: The HTML file that displays the test results has been addressed before I touched it.

Progress

Trigger

(Since it was a long time ago, there are some ambiguous memories, and the details may differ from the actual ones.)

Our team has been using JUnit 4 for a long time, but when we proposed to move to JUnit 5, it was easily accepted. However, in order to do so, it is of course necessary for everyone on the team to be able to use JUnit 5, so we held a JUnit 5 study session within the team easily. During the study session, I also mentioned the @DisplayName and said that I should set @DisplayName as much as possible. I think it was shortly after that, but one of the team members pointed out that the setting value of @DisplayName was not reflected on the display screen of the test result of Jenkins. When I checked it, it was true. This was right after I called to use @DisplayName, so it felt a bit ugly ...

Research of cause

Jenkins reads the XML file of the test result and displays the test result screen, but I knew that from the beginning, so I first took a look at the contents of the XML file. As a result, the class name and method name were output to XML instead of the value of @DisplayName. The cause seems to be not Jenkins, but the tool that generated the XML file. I don't remember how I figured it out, but I found that it was Gradle that generated the XML. In other words, it was because Gradle did not support @DisplayName.

I try to clone somehow

Ignoring the value of @DisplayName doesn't have much effect, but I got interested somehow, so I cloned the Gradle source. When I searched by XML element name or attribute name, only one place was hit. In other words, that was exactly the code that did the XML output processing. I read it briefly, and I can do it with this kind of correction, right? I decided to try it. In the past, I've contributed to Jenkins with only a very minor document fix, so the mental hurdle may have been lowered a bit. Story of participating in OSS Gate Tokyo Workshop 2019-12-14 and contributing to Jenkins

Find out how to contribute

Find out if it's OSS

To contribute to OSS, you first need to make sure that it really is OSS. If it weren't OSS, there would be no contribution ... You can tell if it is OSS by checking the license. As I wrote in the above article (or rather, I wrote this while looking at the above article), if the license is in the list below, it can be said that it is OSS. https://opensource.org/licenses/alphabetical And the license is generally written on the official website or GitHub.

Gradle's license is Apache License 2.0, isn't it? https://github.com/gradle/gradle/blob/master/LICENSE

Since Apache License 2.0 is on the list, Gradle can be said to be OSS.

Survey on how to contribute to Gradle-First pull request

The way you contribute to OSS is different for each OSS. Most of the time, there is a document that describes how to contribute, so look for it. Regarding Gradle, there was the following document, so I proceeded with it according to it. https://github.com/gradle/gradle/blob/master/CONTRIBUTING.md

Of course, it's all in English, so it took me a long time to read ... Normally, the Issue is opened first, but the Issue in this case was already open by another person. https://github.com/gradle/gradle/issues/11445

Then I thought that I should throw a pull request in the form of a correction to this. It seemed easy to fix and the amount of correction was small, so I thought it would be okay to throw a pull request suddenly. It was the same with Jenkins. (Well, I'll realize later that the perception was too sweet ...)

I made corrections, added UTs, checked the operation, wrote a traceable English sentence while relying on translation tools, and threw the first pull request with excitement.

There is a reaction

It's been a while since I threw the pull request, but there was a reaction. According to him, the test failed due to the effect of the correction ... I had confirmed that the test for the project containing the modified source was successful, but the test for another project was failing. I didn't notice it at all ... It's one of the big reflections. In the modification I made, the result when @DisplayName was not given was different from before the modification. Specifically, the class name was FQN before the modification, but after the modification, the class name did not include the package name. I checked the operation, but I did not notice it because there was no difference before and after the modification because I checked it with the class of the default package. It ’s a very embarrassing story ...

Re-correction

In response to the indication, we considered how to fix it. To fix it, you need to determine if @DisplayName is given. At first I thought it wouldn't be that big of a deal, but it turned out to be quite difficult. There should be some code that gets the value of @DisplayName, but it's wider than I imagined and it took me a long time to figure out where the code was. In addition, it is necessary to pass the value from the corresponding code to the first corrected part, but in the process, a considerable number of files will be corrected, and as a result, UT also fails here and there, and it is quite difficult. did. We've also gone through many other types of run-time errors. I was a little regretted that I threw a pull request, saying that I had a harder problem than I expected, but in the end I managed to get it working.

I didn't know what to do if I re-corrected it after throwing a pull request, but when I googled it, it was helpful because such information came out at the top. https://teratail.com/questions/122843

When I fixed the pull request, there was an immediate reaction. I received some indications, but I was happy to receive a comment (probably) to the effect that the direction of the correction was not wrong. For the time being, it seemed that I should simply delete the pointed out part, so I did so.

Request a re-review

After the above correction, I was able to get a review very quickly, but this time I was not able to get a comment on the review. I was wondering why, but apparently it was because I didn't request a review ... I wrote a comment to the effect that it was corrected, so I felt like requesting a review, but apparently I had to submit a review request according to the mechanism of GitHub. It seems that you can request a review by clicking the point to the right of the reviewer's name, so I did so.

Reviewer correction-to merge

I got a response rather quickly after requesting a review, but the pull request I threw was closed, a new pull request was created, and the reviewer re-corrected my modified code. Was merged after. Is it common for reviewers to modify the reviewer's code directly? Well, if you think about it normally, it's not at least a pleasure. I wonder if it was like a ken to leave it to this guy ... Being fixed means that there is a problem, so I thought that I was still lacking in ability.

Well, I was very happy that the code I wrote was merged, even though it was fixed. Also, at one point I was a little regretted about throwing the pull request, so I had a strong feeling that my shoulders were unloaded and I was released because I managed to finish it to the end.

Summary of reflection points

• Insufficient confirmation of operation after correction
• As a result, I misunderstood the difficulty level of correction (I can say that I was able to contribute because of that ... w)
• I didn't notice that the test was failing
• I made the reviewer wait in vain without requesting a review (I didn't know how it works. Insufficient research)
• I didn't write it above, but when I thought about it, I didn't make a fix branch.

It's not a point of reflection, but I'm not afraid of lack of power, so I'd like to study by looking at the corrected differences. (I feel like I should do it quickly ...)

At the end

Actually, I wanted to write an article like "It's not difficult to contribute to OSS! Let's do it for everyone!", But when I actually tried it, it was quite difficult ... It may be easy)

For the time being, I was able to gain the experience of "contribution to OSS" this time, so I thought that I would be able to work with some confidence when the same thing happens again in the future. It has been fixed! </ s>