Front-end gitLab’s initial ATTEMPT at CI

This article documents a CI for a front-end deployment of Gitlab. Not Gitlab built on top of your own server. The CI of Gitlab of Gitlab.com is used, and the small water pipe of Tencent Cloud Can not afford to build Gitlab, so a CI server can be barely done.

Gitlab and making

Github is a website that provides users with space to create a Git repository and store their data files or code.

Gitlab is an online code repository software based on Git implementation, you can use Gitlab to build a system similar to Github, generally used in enterprises, schools and other internal networks to build Git private server.

What is continuous integration

What is continuous integration?

Continuous integration refers to the frequent (multiple times a day) integration of code into the trunk.

The purpose of continuous integration is to allow products to iterate quickly while maintaining high quality. Its core measure is that code must pass automated tests before it can be integrated into the trunk. As long as a single test case fails, integration fails.

Gitlab的CI

Since GitLab 8.0, GitLab CI has been integrated in GitLab. We just need to add a.gitlab-ci.yml file to the project and then add a Runner for continuous integration. And as GitLab upgrades, GitLab CI becomes more and more powerful.

Firstly, understand several basic concepts of Gitlab CI

GitLab-CI

This is a continuous integration system for GitLab, which comes with GitLab, that is, the server on which you install GitLab. No need to think twice. .gitlab-ci.yml is responsible for script parsing.

GitLab-Runner

This is the bearer of script execution, and runner is responsible for the running of script part of.gitlab-ci.yml. Gitlab-ci browsed the. Gitlab-ci. yml file in the project and assigned each Runner to run the corresponding script according to the rules in it. These scripts are used either for test projects or for deployment.

.gitlab-ci.yml

This is a file at the root of a Git project that records a series of phases and execution rules. Gitlab-ci parses the push and calls Runner to run it based on what’s inside.

In simple terms, you use Git version management to Push native code to Remote (in this case, gitlab.com), and then Gitlab notifies your server, the Gitlab-Runner, to run the build task. Then run test cases, test cases passed to generate Build the corresponding environment code, automatically deployed on the different environment server.

Install Gitlab Runner

If you want to use Docker Runner, you need to install Docker. (optional)

curl -sSL https://get.docker.com/ | sh
Copy the code

Installing GitLab Runner is so easy, just follow the tutorial in the official documentation! Debian/Ubuntu/CentOS installation methods are as follows:

# For Debian/Ubuntu
$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash
$ sudo apt-get install gitlab-ci-multi-runner
# For CentOS
$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash
$ sudo yum install gitlab-ci-multi-runner
Copy the code

A Runner needs to register with Gitlab to be used by a project. A Gitlab-CI-multi-Runner service can register multiple Runners.

Register Runner on GNU/Linux:

Run the following command to start the registration process:

sudo gitlab-runner register
Copy the code

Enter the GitLab instance URL:

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
https://gitlab.com
Copy the code

Enter the token obtained for registering Runner:

Please enter the gitlab-ci token forThis runner XXX // This token is under setting >> CI/CD >> Runners Settings for your gitlab.com projectCopy the code

Please enter the gitlab-ci description forThis Runner is a low-configuration serverCopy the code

Assign tags to the Runner, which can also be modified later in GitLab’s UI:

Please enter the gitlab-ci tags forThis runner (Comma Separated): Tengxun // This is the unique ID of each runner, remember the tag.Copy the code

Select whether Runner accepts tasks with unspecified tags (default: false), which can be changed later in GitLab’s UI:

Whether to run untagged jobs [true/false] : [false] :true
Copy the code

Select whether to lock the Runner for the current project or not, and you can modify it later in GitLab’s UI. This feature is usually used for runners assigned to a particular project (default: true) :

Whether to lock Runner to current project [true/false] : [true] :true
Copy the code

Choose the Runner executor:

Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell: Docker // I choose the docker, please remember, before choosing docker to start docker, docker use is not described in this articleCopy the code

If you select Docker as your executor, the registry lets you set a default image for.gitlab-ci.yml projects that do not specify a mirror:

Please enter the Docker image (eg. Ruby :2.1): alpine:latestCopy the code

Then, you refresh the configuration under your Setting

Configuration. Gitlab – ci. Yml

With Runner configured, all we need to do is add the.gitlab-ci.yml file to the project root. When we added the.gitlab-ci.yml file, the build task would run automatically every time we committed code or merged MR.

There are some concepts to explain in.gitlab-ci.yml

Pipeline

A Pipeline is actually a build task, which can contain multiple processes, such as installing dependencies, running tests, compiling, deploying test servers, deploying production servers, etc. Any submission or Merge of our Merge requests can trigger the Pipeline. The diagram below:

+------------------+           +----------------+
|                  |  trigger  |                |
|   Commit / MR    +---------->+    Pipeline    |
|                  |           |                |
+------------------+           +----------------+
Copy the code

Stages

“Stages” refers to the construction stage. Specifically, it is the process mentioned above. We can define multiple Stages in a Pipeline, each of which can perform different tasks. Stages has the following characteristics:

• All Stages run in order, that is, when one Stage is complete, the next Stage begins
• The Pipeline will be successful only when all Stages are complete
• If any of the Stages fails, the Stages that follow do not execute and the build task fails

Therefore, the relationship between Stages and Pipeline is:

+--------------------------------------------------------+
|                                                        |
|  Pipeline                                              |
|                                                        |
|  +-----------+     +------------+      +------------+  |
|  |  Stage 1  |---->|   Stage 2  |----->|   Stage 3  |  |
|  +-----------+     +------------+      +------------+  |
|                                                        |
+--------------------------------------------------------+
Copy the code

Jobs

Jobs stands for build work and represents work performed within a Stage. We can define multiple Jobs in Stages, which have the following characteristics:

• Jobs in the same Stage execute in parallel
• The Stage succeeds only when Jobs in the same Stage all execute successfully
• If any Job fails, the Stage fails, that is, the build task fails

Therefore, the diagram of Jobs and Stage is:

+------------------------------------------+
|                                          |
|  Stage 1                                 |
|                                          |
|  +---------+  +---------+  +---------+   |
|  |  Job 1  |  |  Job 2  |  |  Job 3  |   |
|  +---------+  +---------+  +---------+   |
|                                          |
+------------------------------------------+
Copy the code

These are some of the basic structures in the deployment script, followed by some of the basic components of.gitlab-ci.yml

Here is a simple Deployment script for a Node project.

image: node:alpine  // Default CI deployed docker image

stages:  // First, there are several steps defined in order. All jobs below the step are executed synchronously
  - test  
  - build
  
job1:
  stage: test  // Stages belonging to test
  script:
    - npm run test // The script executed by this job
  only:
    - master  // Listen only for code commits from the master branch
  tags:
    - tengxun  // Which runner to use

job2:
  stage: build
  script:
    - npm run build
  only:
    - master
  tags:
    - tengxun

Copy the code

Job1 = gitlab-ci; job2 = gitlab-ci

List some commonly used keywords, master these can be developed.

The keyword	Whether must	describe
image	no	For docker images, viewdockerThe document
services	no	For the Docker service, viewdockerThe document
stages	no	Define the Construction phase
types	no	Alias of stages (deprecated)
before_script	no	Defines the commands to run before each job
after_script	no	Defines the commands to run after each job
variable	no	Defining build variables
cache	no	Defines a list of files that can be used in subsequent runs

I found that this article explained every key word very clearly, which was a bit of a primer. It’s even clearer than WHAT I wrote.

Gitlab CI YamL official configuration file translation

Setting >> CI/CD >> Secret Variables in your gitlab.com project will define some build variables before setting >> CI/CD >> Secret Variables in your gitlab.com project, because your Gitlab-CI will automatically log in to the server and update the packaged files automatically.

Runner login to your server is not able to use the traditional input account password form, (because all automation, also need to enter the password, that also call what automation). You can only log in through SSH. If you do not know SSH login, please Google. Private keys are definitely not written in yML files because yML files are visible to everyone, so Gitlab-CI can customize private variable names in projects. At least once the project is open sourced, not everyone can see the private key of the deployment server.

Here $SSH_PRIVATE_KEY is the private key generated by your development machine (that is, your development machine). Be sure to copy

-----BEGIN RSA PRIVATE

-----END RSA PRIVATE KEY-----
Copy the code

These things. (This is a pit… ${CI_COMMIT_REF_NAME} is the default keyword for Gitlab CI, since it is rarely allowed to copy the private key). See documentation for details

Finally, I affixed the Tencent cloud small water pipe configuration, pro test useful.

It was a very simple VUE project. Use vue-CLI to generate and publish to the specified directory on the server where the nginx configuration has been configured.

stages:
  - test
  - build
  - deploy

cache:
  key: ${CI_COMMIT_REF_NAME}
  paths:
  - node_modules/

test_dev:
  image: node:alpine
  stage: test
  only:
    - dev
  tags:
    - tengxun
  script:
    - npm run test


build:
  image: node:alpine
  stage: build
  only:
    - master
    - dev
  tags:
    - tengxun
  script:
    - npm set registry https://registry.npm.taobao.org # Set taobao mirror address
    - npm install --progress=false
    - npm run build
  artifacts:  
    expire_in: 1 week
    paths:
      - dist

deploy_dev:
  image: alpine
  stage: deploy
  only:
    - dev
  tags:
    - tengxun
  script:
    - echo "http://mirrors.aliyun.com/alpine/v3.7/main/" > /etc/apk/repositories
    - apk add --no-cache rsync openssh
    - mkdir -p ~/.ssh
    - echo "$SSH_PRIVATE_KEY" >> ~/.ssh/id_dsa
    - chmod 600 ~/.ssh/id_dsa
    - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
    - rsync -rav --delete dist/ "$SERVER_USER_HOST:$SERVER_DEV_PATH"

deploy_master:
  image: alpine
  stage: deploy
  only:
    - master
  tags:
    - tengxun
  script:
    - echo "http://mirrors.aliyun.com/alpine/v3.7/main/" > /etc/apk/repositories
    - apk add --no-cache rsync openssh
    - mkdir -p ~/.ssh
    - echo "$SSH_PRIVATE_KEY" >> ~/.ssh/id_dsa
    - chmod 600 ~/.ssh/id_dsa
    - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
    - rsync -rav --delete dist/ "$SERVER_USER_HOST:$SERVER_MASTER_PATH"
  when: manual
Copy the code

Here, rsync is used to synchronize the Build code, which is actually very simple.

Rsync is an open source tool for fast incremental file transfers. Related articles

Simply put, it allows you to synchronize files between the source computer and the target computer.

Attach the rsync translated document to me

In Gitlab-CI, cache is easily confused with artifacts.

Cache refers to the cache, which is commonly used in dependency installation. If several jobs need to install the same dependency, you can use the dependency to speed up the dependency installation progress. Artifacts are uploaded to GitLab for download or subsequent use. Gitignore files are automatically deleted when each job is started, so you can use either cache or artifacts for dependent installation directories.

The two main differences are as follows:

• The cache is defined, but if this part of the cache and.gitignore duplicate, you still need to reinstall it
• Reinstallation is likely not up to date because you are using a cache
• In particular, development environments that want to use the latest updates every time should remove the cache and use artifacts so that certain updates are guaranteed
• Artifacts are automatically generated and can be sent to the following jobs to decompress the artifacts, avoiding repeated dependencies. If you run gitlab-Runner using the Docker, the cache will generate temporary containers that are not easy to clean
• Artifacts can be set to automatically delete artifacts
• Artifacts are uploaded to the GitLab server and re-downloaded if needed, so this section can also be downloaded and viewed in GitLab

I’m going to use artifacts because we’re going to reuse the files that the job packaged under Dist.

when: manual

Master is generally a value stable version of the code, so it is best to do this manually. When: manual: manual deployment is required. All jobs are automatically executed by default.

Lu Xun once said: there is a domestic accelerated mirror address must use the domestic mirror address

The image address configuration here includes Docker, APK, and NPM. It had to be set. It was stuck here for a long time.

Then we push the code to master and click on the CI/CD panel of your project.

Well, a simple front-end CI attempt is done.

That ‘s all.

The resources

Gitlab CI is used for continuous integration