In previous articles:

GitLab CI Continuous Integration – GitLab Runner installation and registration

GitLab CI Continuous Integration -GitLab Runner

The next step is to start using GitLab CI for project integration. Here, take the Java project as an example, use Gradle as the project automatic build tool and use Gradle to check code quality. For details, see Using Gradle to Check Java Code quality.

.gitlab-ci.yml

Gitlab CI uses YAML files (.gitlab-ci.yml) to manage project configuration. This file resides at the root of the project repository and defines how the project is built.

YAML is a readable format for expressing data sequences. YAML references a variety of other languages, including C, Python, Perl, and takes inspiration from XML, email data formats. YAML is a recursive abbreviation of “YAML Ain’t a Markup Language”(YAML is not a Markup Language). At the time the Language was developed, YAML actually meant “Yet Another Markup Language”(still a Markup Language), but was renamed with a reverse acronym to emphasize the Language’s data-centric, rather than Markup Language focus. — Wikipedia

The.gitlab-ci.yml file defines a set of tasks with constraints that start with the task name and include a script section, an example of.gitlab-ci.yml:


stages:
  - unit-test


UnitTest:
  stage: unit-test
  tags:
    - spring-sample
  script:
    - gradle test
    - gradle jacocoTestReport
    - gradle sonarqube
  when: always

Copy the code

The following describes the meanings of fields in the script

Build script parsing

Stages Defines phases that can be called. By default, stages are defined as build,test, and deploy, and are executed in the following order:

  1. Jobs of the same stage can be executed in parallel.
  2. The job of the next stage is developed and executed after the job of the previous stage succeeds

Here we define a stage: unit-test. UnitTest below is a task defined and executed when stage is unit-test. Tags represent the Gitlab-runner that he needs to execute, in this case in a tag with a spring-sample tag. Script represents the script to be executed. In this example, the script to be executed consists of three steps:

  1. Run gradle tests
  2. Conduct unit test coverage checks
  3. Run Sonarqube for code quality checks

When defines when tasks are executed, which can be on_success, on_failure, always(triggered every code update) or manual(triggered manually).

Before_script defines the commands to run before all jobs, including deployment tasks. It can be an array or a multi-line string after_script defines the commands to run after all jobs. It must be an array or multi-line string. For example:

job:
  before_script:
  - execute this instead of global before script
  script:
  - my command
  after_script:
  - execute this after my script
Copy the code

Cache specifies the file or directory to be cached. For example:

job1:
  script: test
  cache:
    paths:
    - binaries/
    - .config
Copy the code

See the official documentation for more fields.

Run GitLab CI

After the configuration is complete, you can see the related jobs in CI/CD when pushing the code into the repository:

You can trace the cause of the error according to the generated log. The cause of the error is that there is no environment for installing Gradle in Gitlab-ruuner. After installing Gradle environment, the build task runs successfully. Install Java JDK & Gradle in Ubuntu

reference

YAML: Zh.wikipedia.org/wiki/YAML GitLab CI/CD Pipeline Configuration Reference: Docs.gitlab.com/ee/ci/yaml/ through. Gitlab – ci. Yml configuration tasks: github.com/Fennay/gitl…