[JAVA] Formatter avant la révision du code avec des actions GitHub

Soudain, qu'écrivez-vous en code Java?

À mon avis, il existe une nette différence d'efficacité du travail entre les IDE qui sont familiers avec les touches de raccourci et les IDE qui ne le sont pas. Il semble que «vous pouvez choisir IDE» et «vous pouvez choisir un PC» soient traités comme des ventes même sur le site des ingénieurs qui embauchent, et je suis heureux que l'entreprise qui peut choisir soit meilleure que l'entreprise qui ne peut pas réellement choisir. Cependant, lorsque vous entrez dans un environnement où vous pouvez réellement choisir, c'est pourquoi cette situation a tendance à se produire.

1. Les utilisateurs d'IntelliJ modifient le code écrit dans Eclipse (et vice versa)
2. Appliquer le formateur à la main
3. Les différences de code seront difficiles
4. Révision

Je souhaite unifier le formateur si possible. D'un autre côté, il est gênant de créer des règles telles que "Lorsque vous poussez le code source, formatez-le avec l'outil de construction". Vous pouvez demander à chaque personne de définir le pré-commit, mais si vous utilisez GitHub, cela devrait être plus facile si vous le faites vous-même!

Alors, je l'ai mis. Je pense qu'il existe différents outils de construction et formateurs en fonction du projet, mais cet article traite de Gradle + Google Java Format.

Conclusion

1. Introduction de google-java-format-gradle-plugin https://github.com/sherter/google-java-format-gradle-plugin
2. Définissez le flux de travail des actions GitHub https://github.com/tom-myz/shelffy/blob/master/.github/workflows/gradle.yml
3. Émettez un jeton d'accès et enregistrez-le dans le secret du référentiel

Avec cela, il peut être possible de se débarrasser des problèmes qui sont difficiles à examiner en raison d'un format disjoint!

Points à surveiller

Un commit supplémentaire est une commande

Je n'ai pas trouvé de fonction comme la validation du résultat de l'exécution. Il semble n'y avoir d'autre choix que d'écrire sérieusement la commande git.

références git à la branche par défaut

Puisque le déclencheur est pull_request, il réplique localement la branche source de la fusion et y fait référence. …… Rien ne se passe, et si vous sautez la caisse de la succursale, elle sera engagée dans HEAD. l'origine semble être définie.

L'étape pour laquelle la poursuite en cas d'erreur est définie réussit quel que soit le code de fin.

Mettre «if success ()» à l'étape suivante n'a pas de sens. Si la commande A échoue, si vous souhaitez ignorer la commande B et exécuter la commande C ou une version ultérieure,

• Continuer sur erreur avec la commande A et la commande B dans la même étape
• Placez la commande C et ci-dessous à l'étape suivante

Cela semble bon à réaliser avec.

Autre

Je peux l'ajouter si je me souviens de quelque chose. Peut-être pas.

Pas cool

• S'il s'agit d'un référentiel historique, la différence au moment de la candidature sera difficile → Si vous essayez de revenir en arrière, il sera difficile de blâmer après tout
• Le nom d'utilisateur et l'adresse e-mail sont trop spécifiques → Je pense qu'il vaut mieux préparer un utilisateur dédié si vous le faites dans un projet réel
• Essayez à nouveau de formater le commit après avoir appliqué le formateur → De plus, cela prend beaucoup de temps. Je le fais depuis l'installation du JDK, donc même au niveau Hello world, c'est environ une minute et demie.
• Augmentation nette du nombre de commits et de journaux désordonnés → J'avais l'impression de pouvoir jouer au squash, mais je n'étais pas motivé car je n'avais pas assez de Git.

Impressions

GitHub Actions était bien, mais cela m'a pris du temps car je ne savais pas grand-chose sur Git. Que le plus de développeurs possible soient libérés des critiques cosmétiques injustifiées!

Les références

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