** "Code format is not applied." ** The person who pointed out this, the person who was. Isn't he there? This time, I will introduce a mechanism to execute the code format with ** CI tool ** and prevent the developer from executing the formatter.
** A product with a code style specified by the customer ** faced the following problems, resulting in increased man-hours.
: star: ** Case 1. A case where "Code Formatter" is not applied locally and a Pull Request is issued **
: star: ** Case 2. After modifying based on the slip-through code and applying the code formatter, the differences other than the repaired part were extracted **
: star: ** Case 3. Increase man-hours by creating a system for "cross-checking" **
** [Why code formatter is not applied] **
--The code formatter is not described in the development environment construction procedure manual / development flow. (Ambiguous document)
--There is no transfer of flow between development members (development members are in flux)
Even if you prepare a configuration file for the code formatter, it is meaningless if it is not in operation **. Even if you write the documentation well, there is a limit to making sure that all project members have the same development preferences **. Therefore, I wanted to introduce how to apply the code formatter on the CI tool side for code owners who have similar problems.
** Solution idea **: Rather than relying on the development environment, the formatter should be applied automatically before the review is conducted.
The following requirements must be met in order for CI tools to work with code formatters.
For the method described below, we have selected tools that meet the above requirements, but if they do not exist (especially [1.]), please consider making your own.
This sample shall be created under the following specifications.
item | Contents |
---|---|
Programming language | Java |
Code style | Google Java Style GuideCompliant with |
tool | google-java-format |
: star: Point: Since the branch acquired by on pull_reqest is different from the branch that made the Pull Request, it is necessary to explicitly acquire the branch that made the Pull Request at checkout.
name: Reformat Java source code
on:
pull_request:
jobs:
format:
runs-on: ubuntu-latest
steps:
#Check out the pull requested branch(★ ref is the point)
- uses: actions/checkout@v2
with:
ref: ${{ github.head_ref }}
#Java setup
- name: Set up JDK 11
uses: actions/setup-java@v1
with:
java-version: 11
#Git settings
- name: Git settings
run: |
#Git repository settings
git config --local user.name "User name"
git config --local user.email "E-Mail address"
#Executing code format
- name: Code format
run: |
wget -q -O google-java-format.jar \
https://github.com/google/google-java-format/releases/download/google-java-format-1.9/google-java-format-1.9-all-deps.jar
java -jar google-java-format.jar -replace $(git ls-files src/**/*.java)
#Change confirmation
- name: Check for modified files
id: git-check
run: echo ::set-output name=modified::$(if git diff-index --quiet HEAD --; then echo "false"; else echo "true"; fi)
#If it has changed, do a commit push
- name: Push
if: steps.git-check.outputs.modified == 'true'
run: |
git commit -am "Automated :Reformat Java source code."
git push
** PullRequst implemented, new commit with code formatter applied at the time of change is added **
** Change difference **
The above is realized in the following repositories. (Branch: feature/format-action) https://github.com/yukiusa/github-action-auto-java-format-sample/tree/feature/format-action
How was that? This time, I introduced "a mechanism to comply with the rules without depending on the development environment" using CI tools. By implementing this initiative
--Reduce the trouble of creating a development environment --Reduce check man-hours --Reduce the load of reviewers and reviewers
I think that you can expect such effects. We hope that you will find it useful as one of the future business improvement plans.
Thank you for reading to the end.
Recommended Posts