“This article has participated in the call for good writing activities, click to view: the back end, the big front end double track submission, 20,000 yuan prize pool waiting for you to challenge!”

The previous section explained why static code scanning is required and how to use ktLint to scan project code for compliance with Kotlin’s official code style specification. In practice, you can restrict team members from following the specification. After all, you can’t force team members to use gradle to check code every time. What our team uses is combined with the GitLab CI/CD process.

Code review phase selection

Developers often write code without frequent interruptions, so the stage at which code is reviewed and how quickly it is modified to conform to the specification affects the developer’s effectiveness and acceptance of the specification. There are two main stages for a typical developer to develop a project: editor writing code and code hosting. The comparison of inspection tools and characteristics at different stages is as follows:

So in practice we do code checks and alerts in both phases.

  • During the coding phase, use the Ktlint plugin on the Android Studio market. After installation, if the code does not conform to the kotlin official specification, it will be automatically notified and can be formatted and modified with one click.

  • In the code hosting stage, combined with branch management and GitLab CI/CD, when a developer makes a request to merge code, CI/CD will automatically check the code specification, and will not merge the application if it does not meet the specification reminder.

GitLab CI/CD is introduced

GitLab CI/CD as its name implies, the code is stored in GitLab’s Git repository, and GitLab has a set of Continuous Integration and Continuous Delivery process methods. For every change to the remote repository (push, merge, etc.), you can create a set of scripts to automatically build and test your application. With this CI/CD process, we can ensure that the changes introduced into the code pass all the tests, guidelines, and code compliance standards that you have established for your application.

GitLab CI/CD workflow:

As you can see from the figure above, the GitLab CI/CD process requires a tool to execute the CI/CD script and a.gitlab-ci.yml file in the root directory that defines the CI/CD process.

  • GitLab Runner, the tool for executing CI/CD scripts, is separate from GitLab, so GitLab Runner needs to be configured in the GitLab administration background.
  • The.gitlab-ci.yml file, which specifies build, test, and deployment scripts, is basically a YAML file.

The code hosting phase practices the process

In addition to being reminded to install plug-ins within the IDE, our team also checks the GitLab CI/CD automatically when developers merge code into a ‘pre-release branch’ or, if more efficient, every time they push code into GitLab.

Prerequisites for implementing the process:

  • Gitlab sets the ‘pre-release branch’ of the project to be protected from developers pushing code directly into the ‘pre-release branch’ and must make a merge request to merge the ‘functional branch’ code into the ‘pre-release branch’;
  • Gitlab in Gitlab project ‘Settings’ >’ General ‘and expand’ Merge request ‘in’ merge check ‘set to pipeline must succeed, so when Gitlab CI/CD pipeline is not successful can not agree to merge request;
  • Gitlab is configured with available Gitlab Runners. Go to Gitlab project ‘Settings’ >’ CI/CD ‘and open’ Runners’ to view available Runners.
  • Configure the available.gitlab-ci.yml files.

The final result

Given the above figure, you should have a general idea of the process, so let’s show you the path a piece of code takes in Gitlab.

Step1: when the developer completes the development of the “functional branch”, he puts forward the merge request to merge the code of the functional branch into the “pre-release branch”, triggering the pipeline.

Step2: if the code does not meet the specification and the assembly line fails, the wechat notification of the enterprise will be triggered. The developer will modify the code according to the inspection report and submit the code to the “functional branch” to trigger the assembly line again.

Step3: the code conforms to the specification, the assembly line is successful, and the wechat of the enterprise is triggered to notify the manager to conduct code review and merge the code.

Step4: After merging the code successfully, the enterprise will be notified by wechat.

For your reference. Gitlab-ci.yml file

Clone APP_NAME: "Test" WEIXIN_WEBHOOK: "MANAGER_PHONE: "135******4" REPORE_URL: "Report URL" before_script: -chmod +x./gradlew stages: -lint-notify_dev-notify_manager-notify_merge staticAnalysis: stage: lint tags: - dsl script: - ./gradlew ktlint rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event" notifyDev: stage: notify_dev tags: - dsl script: Run the script to notify the submitter of non-compliance, Push - bash /usr/local/dslapp-reports/ notifydev. sh "$APP_NAME" "$WEIXIN_WEBHOOK" "$REPORE_URL" "$GITLAB_USER_NAME" rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event" when: on_failure notifyManager: stage: notify_manager tags: - dsl script: - curl "${WEIXIN_WEBHOOK}" -H 'Content-Type:application/json' -d "{\" msgtype \ ": \" text \ ", \ "text \" : {\ "content \" : \ "* * $APP_NAME have new merger request: \ n * * submission: $GITLAB_USER_NAME \ n merger request title: $CI_MERGE_REQUEST_TITLE\n Check \",\"mentioned_mobile_list\":[\"$MANAGER_PHONE\"]}}" rules: -if: $CI_PIPELINE_SOURCE == "merge_request_event" when: on_success notifyMerge: stage: notify_merge tags: - dsl script: - curl "${WEIXIN_WEBHOOK}" -H 'Content-Type:application/json' -d "{\" msgtype \ ": \" text \ ", \ "text \" : {\ "content \" : \ "* * $APP_NAME merge request has been approved for: \ n * * approved the merger of the request header: $CI_COMMIT_DESCRIPTION\"}}" - echo "+$CI_PIPELINE_SOURCE rules: If the merge request is approved, the merge request is triggered. '$CI_COMMIT_DESCRIPTION =~ /See merge request.*/ && ($CI_COMMIT_BRANCH == "master" || $CI_COMMIT_BRANCH == "dev")'Copy the code

conclusion

The previous section described how to perform a static code scan during both phases of code development and how to use ktLint in conjunction with Gitlab CI/CD to scan project code for compliance with Kotlin’s official code style specification. We also want to customize rules or how to configure Gitlab Runner in the code style specification in practical practice. This part is what we will explain in the next step, please take care of it. If my article is helpful or inspiring to you, please give me a thumbs up 👍🏻 and support me. If there is any mistake, welcome to correct, welcome to discuss, thank you.

Reference documentation

Android static code scanning efficiency optimization and practice Gitlab merge request