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

查看:100
本文介绍了同时在多个平台上运行Gitlab CI的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个C ++项目,该项目已针对多种OS(Linux,Windows,MacOS)以及多种CPU体系结构(i386,x86_64,arm,Aarch64)进行了编译和打包.为此,我使用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 repo和票务系统很好地集成在一起,可以自然使用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容器/系统中运行此作业?到目前为止,我阅读的所有文档均涉及在一个版本集成多个项目

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使用运行程序"执行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

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

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. 标签-标签使您可以将作业固定到流水线标签.您可以使用 tags:条目指定多个标签,这些条目构成一个AND列表(例如 win 标签和 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.

图像-在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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆