Suddenly, what are you writing in Java code?

In my opinion, there is a clear difference in work efficiency between IDEs that are familiar with shortcut keys and IDEs that are not. It seems that "you can choose IDE" and "you can choose PC" are treated as sales even at the site of hiring engineers, and I'm glad that the company that can choose is better than the company that can not actually choose. However, when I enter the environment where I can actually choose, it tends to cause such a situation.

Code written in Eclipse edited by IntelliJ users (and vice versa)
Apply formatter by hand
Code diffs will be hard
Review

I want to unify the formatter if possible. On the other hand, it is troublesome to make rules such as "When pushing the source code, format it with the build tool". You can ask each person to set the pre-commit, but if you are using GitHub, it should be easier if you do it yourself!

So, I set it. I think there are various build tools and formatters depending on the project, but this article deals with Gradle + Google Java Format.

Conclusion

Introduced google-java-format-gradle-plugin https://github.com/sherter/google-java-format-gradle-plugin
Set the workflow of GitHub Actions https://github.com/tom-myz/shelffy/blob/master/.github/workflows/gradle.yml
Issue an access token and register it in the repository secret

With this, it may be possible to get rid of problems that are difficult to review due to disjointed format!

Points to watch out for

Additional commit is a command

I couldn't find a function like commit the execution result. There seems to be no choice but to write the git command seriously.

git references to default branch

Since the trigger is pull_request, it replicates the merge source branch locally and references it. …… Nothing happens, and if you skip the checkout of the branch, it will be committed to HEAD. origin seems to be set.

The step for which continue-on-error is set succeeds regardless of the exit code.

Putting ʻif success ()` in the subsequent step is meaningless. If command A fails, if you want to skip command B and execute command C or later,

Continue-on-error with command A and command B in the same step
Command C and below are placed in the next step

It seems to be good to realize with.

Other

I may add it if I remember something. May not.

Not cool

If it is a historic repository, the difference at the moment of application will be difficult. → If you try to go back to before that, it will be difficult to git blame after all
Username and email address are too specific → I think it is better to prepare a dedicated user if you do it in an actual project
Try to format the commit again after applying the formatter → Moreover, it takes a long time. I've been doing it since installing the JDK, so even at the Hello world level, it's about a minute and a half.
Net commits and messy logs → I felt like I could go with squash, but I wasn't motivated because Git wasn't enough.

Impressions

GitHub Actions was good, but it took me a long time because I didn't know much about Git. May as many developers as possible be freed from cosmetic reviews without justice!

References

https://help.github.com/ja/actions http://nomadblacky.hatenablog.com/entry/2018/10/27/145451

Formatter before code review on GitHub Actions