gitlab-ci from entry to almost giving up

1 Introduction

I have been deploying with jeakins before. I recently learned about gitlab-ci and wanted to try it. I encountered many pits in the middle.
Briefly record it, and then talk about some of your understanding of deployment.

2. gitlab-ci

Introduction

What I understand about front-end CICD is that the code is continuously integrated into the remote branch after various local verifications, and then triggers a list of actions (such as installation, packaging, testing, deployment).
Usually two servers are required,
One is the ci server, which is used to run various tasks (installation, packaging, testing, deployment, etc.)
The other is the deployment server, which can be an nginx, to display static resources.
Jeakins can be understood as a ci server.
Of course, gitlab itself also provides a ci server, that is gitlab-ci
During this period, I encountered a lot of pits and almost collapsed.

Install the pit of the runner

If it is a gitlab project, in setting-cicd, the left side is the private runner, and the right side is the runner provided by others
runner can be simply understood as running on the ci server ci服务
However, it should be noted that other people's runners may not be suitable for you, because the environment on their ci server may be a java environment, no node is installed, and some global packages you need are not installed. Therefore, you generally need to make a front-end general runner that matches your own project.

The first step: runner server selection <br>First of all, if you are a personal gitlab project, then you can find any server at will. But you are a company's project, and finally find a company intranet server to install, the external network server may not be able to access your company's own gitlab.
Step 2: Install the runner method If you choose <br>, you can refer to the official website for installation . There are several ways. But for me, because the company's server cannot access the scientific ~ Internet ~, downloading the installation package is very slow, so slow that it crashes That kind, so I directly use the method of downloading the installation package first, and then installing it. Note that the corresponding installation package for linux x86_64 is amd64, make no mistake.

Step 3: Install global dependencies
Runner is just a service in the ci server. If the package cannot be found locally, it must be found globally.
Therefore, the ci server needs to install git nvm (manage node) nrm (manage npm source) vue-cli-serve and other common global packages.

Step 4: Register runner
Registration is very simple, in fact, runner and gitlab establish a link

gitlab-runner register follow the prompts step by step, it must be the ci server that can connect to gitlab
After the token and url are found in the setting-runner, you can find that one more custom runner is available.

Step 5: Change runner permissions <br>Must be executed with root permissions, the default user runner company's server does not recognize

 sudo gitlab-runner uninstall # 删除gitlab-runner

gitlab-runner install --working-directory /home/gitlab-runner --user root   # 安装并设置--user(设置为root)

sudo service gitlab-runner restart  # 重启gitlab-runner

ps aux|grep gitlab-runner  # 查看当前runner用户

3. Run through the deployment service

.gitlab-ci.yml

Add the .gitlab-ci.yml file under the project root directory, and gitlab starts the runner according to this file each time it is submitted.
For the specific meaning, you can search for it yourself, and I will only mention a few key places.

• The runner has a name, my runner is called fyy, and the tag parameter is used to execute the runner that needs to be triggered
• stage is a stage, there are generally three stages (plus code detection such as unit testing and integration testing can be four)
• After each stage is completed, the generated files will be deleted, so it needs to be cached
• The only parameter specifies which branch changes only trigger the runner

A usable reference script

 stages:
  - install
  - build
  - deploy
cache: # 缓存
  paths:
    - node_modules
    - dist
第一阶段-install:
  tags:
    - fyy
  stage: install
  script:
    - pnpm install
    - echo '依赖安装成功!'
  only:
    - mono-dp

第二阶段-build:
  tags:
    - fyy
  stage: build
  script:
    - pnpm buildTest
    - echo '测试环境代码打包成功!'
  only:
    - mono-dp

第三阶段-deploy:
  tags:
    - fyy
  stage: deploy
  script:  # 具体的部署方式，这里是常规的部署，也可以容器化部署
    - cd dist
    - tar -cf dist.tar --exclude=./dist.tar .
    - 具体的shell脚本（ssh链接，拷贝到指定目录，解压之类的）
  only:
    - mono-dp

The pit installed by npm

At this time, it is basically OK. Mono-dp push will trigger the ci operation, and you can see the process in the pipeline.
The problem I encountered is that some errors will be reported when npm is installed, which should be caused by a problem with my pnpm.lock file.
To troubleshoot the problem, you can directly log in to the remote server and try it manually. Manually check it in the runner's project directory /home/gitlab-runner/builds/-qUnF6qy/0/webproject/convergencemarketing/ npm insatll build. Don't go through the ci process at this time, it will be very slow.

runner packaged pit

The problem I encountered is that the project has some dependencies on the global package. For example, there is a package called chalk, which is not written in the Package. When ci is not in the Package, it will not be installed, resulting in a packaging error. The solution is to check, the project does not need to be installed. There are dependencies on global packages, all of which are changed to local ones, but there is no way for vue-cli-serve. Only the ci server can be installed globally

4. Summary and reflection

Finally, light up the successful screenshot

Generally speaking, it is very similar to jekins. It is more suitable for team development and large-scale project development, and the process is relatively clear.
But there are also some disadvantages. It feels relatively slow. My project takes about 12 minutes and this still has pnpm+ cache.
For a small company and small project like me, it would be more suitable to package it locally and upload it for deployment (using a deployment service written by myself, or directly using upload software or custom plugin) (it can be controlled within 1 minute).