Gitlab CI 同时在多个平台上 [英] Gitlab CI in multiple platforms simultaneously

问题描述

我有一个针对多个操作系统(Linux、Windows、MacOS)以及多个 CPU 架构(i386、x86_64、arm、Aarch64)编译和打包的 C++ 项目为此，我使用 Jenkins 来获取源代码并在每个系统上并行运行构建脚本.这是一个简单的工作解决方案，因为我的构建脚本处理系统差异.

I have a C++ project that is compiled and packaged for multiple OS (Linux, Windows, MacOS) as well as multiple CPU architectures (i386, x86_64, arm, Aarch64) For this I'm using Jenkins to grab the source code and run the build script in parallel on each system. It's a simple working solution, since my build script deals with the system differences.

现在我正在研究 Gitlab CI/CD，它有很多我觉得很有吸引力的东西(能够将构建脚本保留为存储库的一部分，与 git 存储库和票务系统很好地集成，自然使用Docker 容器等)，但我找不到任何方法在相互并行的多个架构/系统中运行相同的管道.

Now I'm looking into Gitlab CI/CD, and it has many things I find appealing ( being able to keep the build script as part of the repository, very well integrated with the git repo and ticketing system, natural use of Docker containers, etc), but I cannot find any way to run the same pipeline in multiple architectures/systems parallel to each other.

所以，假设我的构建脚本是:

So, say that my build script is:

build:
  stage: build
  script: 
    - uname -m > arch.txt
  artifacts:
    paths:
      - arch.txt

如何告诉 Gitlab 我想同时在多个运行器/Docker 容器/系统中运行此作业?到目前为止，我阅读的所有文档都涉及 在一个构建，集成多个项目或根据分支部署在不同的环境中.到目前为止，我读过的任何内容都没有尝试进行许多单独的构建，单独测试和打包它们并报告它们的独立结果.这在 Gitlab CI/CD 上可行吗?

How can I tell Gitlab that I want to run this job in multiple runners/Docker containers/systems at the same time? All the documentation I've read so far deals with running multiple tests on one build, integrating multiple projects or deploying in different environments depending on branches. Nothing I've read so far tries to do many separate builds, test and package them individually and report on their independent results. Is this feasible on Gitlab CI/CD?

推荐答案

GitLab 使用runners"来执行 CI 作业.运行程序安装在您想要运行 CI 作业的任何位置，因此如果您想在多个架构上运行，那么您需要在每个架构的系统上安装运行程序.Runner安装文档可以在这里找到:

GitLab uses "runners" to execute CI jobs. Runners are installed wherever you want to run a CI job, so if you want to run on multiple architectures then you will need to install runners on systems for each architecture. Runner install documentation can be found here:

https://docs.gitlab.com/runner/install/index.html

对于基于 Linux 的作业，通常使用 Docker 来执行作业 - 这不会提供架构灵活性，但它确实允许您使用容器化在不同的风格和不同的软件上进行测试.对于其他架构，您可能需要自己安装运行器，或使用其他人共享的运行器.

For Linux-based jobs it is common to use Docker for job execution - this doesn't give architectural flexibility, but it does allow you to test on different flavors and with different software using containerisation. For other architectures you may need to install runners yourself, or use other peoples shared runners.

在安装运行器软件时，有一些关键步骤:

While you are installing the runner software there are some keys steps:

• 您可以将每个跑步者链接到您的 GitLab 项目，这意味着它将显示在项目 > 设置 > CI/CD 下的跑步者列表中.

• you have the opportunity to link each runner to your GitLab project, which means it will show up in the runners list under Project > Settings > CI/CD.

您将有机会为跑步者分配标签".标签可用于通过任意名称帮助识别跑步者或跑步者组(例如，您可以添加Windows x86_64"作为标签，或Windows"和x86_64"标签).这些标签可用于作业中选择跑步者.

you will have the opportunity to assign "tags" to the runners. Tags can be used to help identify a runner or group of runners by an arbitrary name (e.g. you could add "Windows x86_64" as a tag, or "Windows" and "x86_64" tags). These tags can be used in jobs to select a runner.

一旦你安装了跑步者，你就可以开始编辑你的 .gitlab-ci.yml 文件了.

Once you have your runners installed you can get editing your .gitlab-ci.yml file.

GitLab CI 文件分为阶段".每个阶段的作业可以并行运行.阶段名称在文件顶部定义.

GitLab CI files are broken up into "stages". Jobs in each stage can run in parallel. Stage names are defined at the top of the file.

stages:
  - build
  - deploy

每个 CI 作业都可以使用 stage: 条目附加到一个阶段:

Each CI job can be attached to a stage by using the stage: entry:

build job:
  stage: build
  script:
    - echo "I am a build stage job"

在您的情况下，您需要为要构建的每个架构创建多个作业.将它们附加到同一阶段将允许它们并行运行.

In your case you will need to create multiple jobs for each architecture you want to build for. Attaching these to the same stage will allow them to run in parallel.

要控制每个作业的运行位置，您有两个主要机制:

To control where each job runs you have two main mechanisms:

1. 标签 - 标签允许您将作业固定到运行器标签.您可以使用形成 AND 列表的 tags: 条目指定多个标签(例如 win 标签 AND x86_64 标签).当该作业运行时，GitLab 将找到一个具有所有必需标签的运行器，并在那里运行该作业.

1. Tags - tags allow you to pin a job to a runner tag. You can specify multiple tags using the tags: entry which forms an AND list (e.g. win tag AND x86_64 tag). When that job runs GitLab will find a runner that has all the required tags, and run the job there.

Image - 在 Docker/Kubernetes 上运行时，您可以指定用于运行器的 docker 映像.要使用 docker 镜像，您首先需要指定一个可以运行 docker 镜像的运行器(例如 docker-in-docker 或 kubernetes 运行器)，例如，它可能被标记为 docker 或 kubernetes.然后使用 image: 条目来指定 docker 图像.

Image - When running on Docker / Kubernetes you can specify a docker image to use for the runner. To use a docker image you first need to specify a runner that can run docker images (e.g. a docker-in-docker or kubernetes runner), which might, for example, be tagged with docker or kubernetes. Then you use the image: entry to specify the docker image.

这是一个同时显示标签和图像的示例:

Here's an example showing both tags and images:

build win x86_64:
  stage: build
  tags:
    - win
    - x86_64
  script:
    - echo "I am a build stage job for win x86_64"

build win 32:
  stage: build
  tags:
    - win
    - 32-bit
  script:
    - echo "I am a build stage job for win 32"

build debian:
  stage: build
  tags:
    - docker
  image: debian:stretch
  script:
    - echo "I am a build stage job for debian, running on docker using debian:stretch image"

目前不支持动态作业，或在多个运行器/架构上运行一个作业，因此这需要一些手动操作.从积极的方面来说，它使 GitLab CI 文件易于阅读，并且易于查看 CI 执行期间将运行的内容.

There is currently no support for dynamic jobs, or running one job on multiple runners / architectures, so this involves a bit of manual effort. On the positive side it makes GitLab CI files easy to read, and easy to see what will run during CI execution.

这篇关于Gitlab CI 同时在多个平台上的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！