[JAVA] Formatierer vor Codeüberprüfung mit GitHub-Aktionen

Was schreiben Sie plötzlich in Java-Code?

Meiner Meinung nach gibt es einen deutlichen Unterschied in der Arbeitseffizienz zwischen IDEs, die mit Tastenkombinationen vertraut sind, und IDEs, die dies nicht sind. Es scheint, dass "Sie können IDE wählen" und "Sie können PC wählen" selbst bei der Einstellung von Ingenieuren als Verkäufe behandelt werden, und ich bin froh, dass das Unternehmen, das wählen kann, besser ist als das Unternehmen, das nicht wählen kann. Wenn Sie jedoch eine Umgebung betreten, in der Sie tatsächlich auswählen können, tritt diese Situation in der Regel auf.

1. IntelliJ-Benutzer bearbeiten in Eclipse geschriebenen Code (und umgekehrt)
2. Formatierer von Hand auftragen
3. Codeunterschiede werden schwierig sein
4. Überprüfen

Ich möchte den Formatierer nach Möglichkeit vereinheitlichen. Auf der anderen Seite ist es schwierig, Regeln wie "Wenn Sie den Quellcode pushen, formatieren Sie ihn mit dem Build-Tool" zu erstellen. Sie können jede Person bitten, das Pre-Commit festzulegen, aber wenn Sie GitHub verwenden, sollte es einfacher sein, wenn Sie es alleine tun!

Also habe ich es eingestellt. Ich denke, es gibt je nach Projekt verschiedene Build-Tools und Formatierer, aber dieser Artikel befasst sich mit Gradle + Google Java Format.

Fazit

1. Einführung des Google-Java-Format-Gradle-Plugins https://github.com/sherter/google-java-format-gradle-plugin
2. Legen Sie den Workflow für GitHub-Aktionen fest https://github.com/tom-myz/shelffy/blob/master/.github/workflows/gradle.yml
3. Stellen Sie ein Zugriffstoken aus und registrieren Sie es im Geheimnis des Repositorys

Auf diese Weise können möglicherweise Probleme behoben werden, die aufgrund des unzusammenhängenden Formats schwer zu überprüfen sind!

Punkte, auf die Sie achten sollten

Zusätzliches Commit ist ein Befehl

Ich konnte keine Funktion wie das Ausführungsergebnis festschreiben finden. Es scheint keine andere Wahl zu geben, als den Befehl git ernsthaft zu schreiben.

Git-Verweise auf Standardzweig

Da der Trigger "pull_request" ist, dupliziert er den Zweig der Zusammenführungsquelle lokal und verweist darauf. …… Es passiert nichts, und wenn Sie das Auschecken der Filiale überspringen, wird es an HEAD übergeben. Ursprung scheint gesetzt zu sein.

Der Schritt, für den "Continue-on-Error" festgelegt ist, ist unabhängig vom Endcode erfolgreich.

Das Setzen von "if success ()" in den nachfolgenden Schritt ist bedeutungslos. Wenn Befehl A fehlschlägt, wenn Sie Befehl B überspringen und Befehl C oder höher ausführen möchten,

• Weiter mit Fehler mit Befehl A und Befehl B im selben Schritt
• Platzieren Sie im nächsten Schritt den Befehl C und darunter

Es scheint gut zu sein, damit zu realisieren.

Andere

Ich kann es hinzufügen, wenn ich mich an etwas erinnere. Nicht dürfen.

Nicht cool

• Wenn es sich um ein historisches Repository handelt, ist der Unterschied zum Zeitpunkt der Anwendung schwierig → Wenn Sie versuchen, vorher zurückzukehren, wird es schwierig sein, die Schuld zu geben
• Benutzername und E-Mail-Adresse sind zu spezifisch → Ich denke, es ist besser, einen dedizierten Benutzer vorzubereiten, wenn Sie dies in einem tatsächlichen Projekt tun
• Versuchen Sie, das Commit nach dem Anwenden des Formatierers erneut zu formatieren → Außerdem dauert es lange. Ich mache das seit der Installation des JDK. Selbst auf der Ebene von Hello World sind es ungefähr anderthalb Minuten.
• Die Anzahl der Commits hat sich netto erhöht und das Protokoll ist unordentlich → Ich hatte das Gefühl, ich könnte mit Squash spielen, aber ich war nicht motiviert, weil ich nicht genug Git hatte.

Impressionen

GitHub Actions war gut, aber es hat lange gedauert, weil ich nicht viel über Git wusste. Mögen so viele Entwickler wie möglich ohne Gerechtigkeit von kosmetischen Bewertungen befreit werden!

Verweise

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