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

In the previous article, how to cooperate with GitLab CI/CD to implement the unity of team code style specification in practice, and GitLab CI/CD process needs GitLab Runner tool to run the assembly line job to be executed in the corresponding project. Of course, the GitLab Runner configuration you can spend $10 to buy the operation brother a cup of Michelle Ice City, and then ask him to help. If you want to learn more about configuring GitLab Runner and writing.gitlab-ci.yml, read on.

Introduction of GitLab Runner

To review the GitLab CI/CD workflow:

  • First, define the.gitlab-ci.yml file. The job and command to be executed are defined in this file.
  • Next, push the local files to the remote repository;
  • Finally, the remote repository notifies Runner to execute the job defined in the.gitlab-ci.yml file.

GitLab and Runner communicate with each other through API, so it only needs the machine where Runner is located to have network and access to GitLab server. In other words, Runner can not be in the same environment with GitLab. A Runner can be deployed in another VIRTUAL machine, physical machine, Docker container, or a container cluster.

Runner internally defines a number of Executors that can be used to run the build in different scenarios, such as Shell and Docker.

The Docker executor can use the rich image images on the network to easily create a construction environment with dependent services. However, downloading image images will encounter many problems under the complex domestic network. In addition, every build is a new environment, and the files generated by the build cannot be saved for a long time. However, our team generates code reports every time we build, and we do not want to upload the code reports to another place to save every time, so our team chose Shell executor.

GitLab Runner installation practices

  1. The installation

You can run this command on the server to query the server system

lsb_release -a
Copy the code

The practical server system is CentOS Linux Release 7.6.181(core-4.1-AMD64).

Add GitLab’s official repository

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" | sudo bash
Copy the code

Install the latest version of GitLab Runner

sudo yum install gitlab-runner
Copy the code
  1. Register, associate with Gitlab
[root@localhost ~]# gitlab-runner register Running in system-mode. Such as http://gitlab.example.com/ do enter the gitlab - ci coordinator URL (e.g., https://gitlab.com/) : http://xxx.xxx.xxx:xxx/ # bootstrap will ask you to enter the token, go to the corresponding item and find the token, For example, xrjc3tWcdQpLcEwoYzkU Please enter the gitlab-ci token for this runner: Please enter the gitlab-ci description for this runner: [localhost. Localdomain]: Develop # bootstrap will ask you to type tag, there may be multiple runners for a project, the runners are identified according to the tag, type as many as possible, such as Web,hook,deploy,develop. Gitlab-ci tags for This Runner (Comma Separated) Please enter the gitlab-ci tags for this Runner (Comma separated): Develop # Whether to run untagged builds [true/false]: [true/false]: [false]: true Registering Runner... Succeeded Runner =xrjc3tWc # Booting will ask you to enter the executor type, and we'll type shell Please enter the executor: shell, ssh, docker+machine, docker, docker-ssh, parallels, virtualbox, docker-ssh+machine, kubernetes: shell Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!Copy the code
  1. Configuration is complete

After the configuration is complete, you can see the Runner in Gitlab -> Settings -> CI/CD -> Runner expansion.

.gitlab-ci.yml

A brief introduction. Gitlab – ci. Yml

Tell CI what to do with your project by configuring the.gitlab-ci.yml file in the project root directory. One can have multiple jobs, and these jobs are combined into a complete pipeline.

This is where the complete pipeline jobs are defined and the order in which they are executed.
stages:
  - build
  - test

job-0:
  stage: build
  # tags defines which Runner executes the job.
  tags:
    - dsl
  # Command to execute the job.
  script:
    - echo "Check the java version, then build some Ruby project files:"
    All commands under the shell executor must run properly on the Runnner machine, that is, to execute Java -version. The Runnner machine must have the Java environment configured.
    - java -version

job-1:
  stage: test
  tags:
    - dsl
  script:
    - echo "If the files are built successfully, test some files with one command:"
    - ./gradlew app:assembleRelease
  # rules specifies when the job is executed. Here, it is defined that job 1 is executed only when job 0 fails in the pre-stage.
  rules:
    - when: on_failure
Copy the code

The syntax of the.gitlab-ci.yml file and its custom variables will not be detailed here. For more information, please refer to the official.gitlab-ci.yml documentation.

Simple implementation of ktLint scan task. Gitlab-ci.yml

GIT_STRATEGY is to tell Runner how to obtain the latest code at each CI/CD (later called: job), set it to Clone, each time the job will clone the repository
variables:
 GIT_STRATEGY: clone
 APP_NAME: "Test"
 WEIXIN_WEBHOOK: "Enterprise wechat Robot Address"
 MANAGER_PHONE: "135 * * * * * * 4"
 REPORE_URL: "Report Website"
This is the command that is executed before each job. In this case, this is the command that lifts gradlew file and gives execution permission
before_script:
 - chmod +x ./gradlew
Lint (static check), notify_dev(notify_dev), notify_Manager (notify_manager), and notify_merge(publish merge)
stages:
 - lint
 - notify_dev
 - notify_manager
 - notify_merge
staticAnalysis:
 stage: lint
 tags:
   - dsl
 script:
   - ./gradlew ktlint
 rules:
   The job is executed only if it belongs to a merge request
   - if: $CI_PIPELINE_SOURCE = = "merge_request_event"
notifyDev:
 stage: notify_dev
 tags:
   - dsl
 script:
   # Run the script to notify the submitter that it does not meet the specification. Please modify the report and push again
   - bash /usr/local/dslapp-reports/notifyDev.sh "$APP_NAME" "$WEIXIN_WEBHOOK" "$REPORE_URL" "$GITLAB_USER_NAME"
 rules:
   The job is executed only if it belongs to a merge request and the previous job failed
   - 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 please note audit \ ", \ "mentioned_mobile_list \" : [\ "$MANAGER_PHONE \]}}"
 rules:
   This job is executed only if it belongs to the merge request and the previous job was successful
   - 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 "Upon approval of the merger request :"+$CI_PIPELINE_SOURCE
 rules:
   'See merge request' is triggered when the merge request is approved
   - if: '$CI_COMMIT_DESCRIPTION =~ /See merge request.*/ && ($CI_COMMIT_BRANCH == "master" || $CI_COMMIT_BRANCH == "dev")'
Copy the code

The GitLab Runner machine configures the Android environment

The GitLab Runner machine must have an environment that can execute the commands you define, and if the executor is Docker it can download the appropriate image. But we chose the Shell executor. The environment is not isolated from the machine on which Runner is installed, but the same environment is used. So we need to configure the Android environment in advance, the front mentioned installation Runner system of the machine is on my side CentOS Linux release 7.6.181 (core – 4.1 – amd64), the following configuration can perform ktlint check command environment.

  • Configure the JDK 
    Use the browser tool to download jdk1.8 after login. Run the wget command to download the jdk1.8 package. Wget https://download.oracle.com/otn/java/jdk/8u291-b10/d7fc238d0cbf4b0dac67be84580cfb4b/jdk-8u291-linux-x64.tar.gz?AuthParam =1626056251_3a0fae7d2e6b819092bf9ffb8d15db2dCopy the code
    Tar -zxvf jdk-8u291-linux-x64.tar.gz -c /usr/local/Copy the code
    Export JAVA_HOME=/usr/local/jdk1.8.0_291, export PATH=$PATH:$JAVA_HOME/bin, The java_home. vim /etc/profile configuration is completeCopy the code
    # reload system environment variable source /etc/profileCopy the code
  • Configuration androidSdk 
    Mkdir /usr/local/android-sdk-linuxCopy the code
    # download [androidSdk command line tools only] (https://developer.android.com/studio#command-tools). The wget https://dl.google.com/android/repository/commandlinetools-linux-6858069_latest.zipCopy the code
    Unzip commandlineTools-linux-6858069_latest. Zip: unzip commandlineTools-linux-6858069_latestCopy the code
    /etc/profile: export ANDROID_SDK_ROOT=/usr/local/ android-sdK-linux, export PATH=$PATH:$ANDROID_SDK_ROOT/cmdline-tools. vim /etc/profileCopy the code
    # reload system environment variable source /etc/profileCopy the code

conclusion

Above, Runner and.gitlab-ci.yml are briefly introduced, as well as how to configure Runner and the Android environment. Stay tuned for how to customize kTLint rules. If my article is helpful or inspiring to you, please give me a thumbs-up 👍🏻 and support me. If there is a mistake, welcome to the leaders to correct, but also welcome to discuss, thank you.

Reference documentation

GitLab Runner official document GitLab Runner installation official document. GitLab -ci.yml official document