gitLab是一个仓库管理平台，其支持Saas和自管理安装方式。对于一般的需求，免费版本就已经足够使用。在国内环境中，我们可以使用极狐GitLab。

自托管安装

当我们对于代码有自托管要求的时候，我们就需要对GitLab进行自托管的安装了。

安装GitLab

Centos7安装

  1. 安装必要的服务 ``` sudo yum install -y curl policycoreutils-python openssh-server perl sudo systemctl enable sshd sudo systemctl start sshd sudo firewall-cmd —permanent —add-service=http sudo firewall-cmd —permanent —add-service=https sudo systemctl reload firewalld

sudo firewall-cmd —permanent —add-service=http sudo firewall-cmd —permanent —add-service=https sudo systemctl reload firewalld

  2. 2. 下载并安装
  3. ```bash
  4. wget https://omnibus.gitlab.cn/el/7/gitlab-jh-14.7.2-jh.0.el7.x86_64.rpm
  5. sudo rpm -Uvh gitlab-jh-14.7.2-jh.0.el7.x86_64.rpm
  1. 访问GitLab实例

当我们安装完成了GitLab后，要尽量早的访问GitLab的实例。因为在我们的安装过程中没有指定管理员的自定义密码，所以GitLab为我们初始化了一个密码。这个密码保存在/etc/gitlab/initial_root_password文件中，因为安全原因，这个文件后在24小时后自动删除。所以我们要尽早访问GitLab实例，使用用户名root和文件中指定的密码登录，并修改root的密码。

  1. 后续配置

在我们安装完成GitLab后，基本工作就算是完成了。下来就是我们对于GitLab的进一步的管理和配置了。其中就有gitlab-runner(在GitLab中使用CI/CD功能时需要我们使用gitlab-runner)的安装和配置。

安装 gitlab-runner

当我们使用gitlab时，我们通常会使用到gitlab的CI/CD功能。使用这个功能的前提是每个项目都有对应的gitlab-runner，所以我们就需要搭建自己的gitlab-runner，使用自己搭建的gitlab-runner是没有分钟数限制的。

docker安装

使用docker安装gitlab-runner的前提是我们已经安装好了docker。如果没有安装，可以参考docker安装。

  1.    docker run -d --name gitlab-runner --restart always \
  2.      -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  3.      -v /var/run/docker.sock:/var/run/docker.sock \
  4.      gitlab/gitlab-runner:latest

注册gitlab-runner服务：

  1. docker run --rm -it -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register

命令行

常用命令行

  1. gitlab-ctl start
  2. gitlab-ctl stop
  3. gitlab-ctl restart

使用

CI/CD

当我们需要在GitLab中使用CI/CD的时候，我们需要编写.gitlab-ci.yml文件。我们编写的.gitlab-ci.yml文件依据其中的配置在合适的时机触发GitLab的CI/CD。

.gitlab-ci.yml文件

在gitlab-ci.yml中，我们可以定义以下内容：

  • 要运行的脚本
  • 要包含的其他配置文件和模板
  • 依赖项和缓存
  • 要按顺序运行的命令和要并行运行的命令
  • 将应用程序部署到的位置
  • 无论是想自动运行脚本还是手动触发它们中的任何一个

当我们配置gitlab的.gitlab-ci.yml的时候，我们通常会通过配置stages项来自定义运行的不同阶段。当然，gitlab也为我们默认配置了一部分的阶段(当我们没有在.gitlab-cli.yml中显式指定stages时，会启用这些阶段)：

  • .pre
  • build
  • test
  • deploy
  • .post

在这些自定义的阶段中，执行顺序是按照.pre -> build -> test -> deploy -> .post的顺序执行的。而各位阶段之中的脚本是并行执行的。

阶段(stages)

除了使用gitlab中默认配置的阶段外，我们还可以通过使用stage关键字来自定义一些阶段。比如：

  1. stages:
  2.     - prepare
  3.   - build
  4.   - test
  6. job prepare:
  7.     stage: prepare
  8.   script:
  9.       - echo "prepare"
  11. build:
  12.     script:
  13.       - echo "build"
  15. test:
  16.     script:
  17.       - echo "test"
  1. 其中的`prepare`就是我们自定义的阶段，需要注意的是，如果我们使用了自定义的阶段，那么我们就要通过在某个`job`中使用`stage`关键字来指定其阶段是属于`prepare`阶段的。如果没有job属于`prepare`阶段，那么`.gitlab-cli.yml`就是不合法的。这里需要指出的是，我们在`.gitlab-ci.yml`中指定的`job`一定要定义一个`script`，否则这个`job`就是非法的。

镜像(image)

当我们在gitlab中要运行特定的环境时，我们就可以通过image关键字指定特定的镜像来实现。比如：node。如下：

  1. image: node-latest

示例

  • 使用pnpm自动测试用例 ```yaml image: node:latest

测试: stage: test before_script:

  1. - curl -f https://get.pnpm.io/v6.16.js | node - add --global pnpm@6
  2. - pnpm config set store-dir .pnpm-store
  3. - pnpm config set registry https://registry.npmmirror.com/

script:

  1. - pnpm install
  2. - pnpm test

cache: key: “$CI_COMMIT_REF_SLUG” paths:

  1.   - .pnpm-store
  1. <a name="yEZG3"></a>
  2. ### 使用gitlab来自动测试Rust包
  3. 当我们要使用`gitlab`来自动测试Rust包的时候，最简单的配置文件就是这样的：
  4. ```yaml
  5. image: "rust:latest"
  7. test:cargo:
  8.   script:
  9.     - rustc --version && cargo --version
  10.     - cargo test --workspace --verbose

这就是我们最简单的配置文件，但是因为图内环境的原因，当我们运行cargo test时，cargo索引会很慢，会很影响构建速度，甚至可能因为这个原因失败。那么，我们怎样才能解决这个问题呢？
其实呢，解决这个问题很简单，我们只需要在我们rust项目的根目录下创建一个.cargo目录，并在其中建立一个config.toml文件。在文件中配置一下cargo的国内镜像就可以了：

  1. [source.crates-io]
  2. replace-with = 'tuna'
  4. [source.tuna]
  5. registry = "https://mirrors.tuna.tsinghua.edu.cn/git/crates.io-index.git"

之所以这个方法有用，是因为在cargo中，读取配置文件的优先级为：/projects/.cargo/config.toml > /.cargo/config.toml，所以我们在项目中指定的 .cargo/config.toml 是有效的。

欢迎赞赏

不收费阅读，但希望如果能够帮助你的话，可以给个赞赏。

GitLab - 图1