在项目之间共享 gitlab-ci.yml [英] Share gitlab-ci.yml between projects

问题描述

我们正在考虑将我们的 ci 从 jenkins 转移到 gitlab.我们有几个具有相同构建工作流程的项目.现在我们使用一个定义了管道的共享库，项目中的 jenkinsfile 只调用在定义实际管道的共享库中定义的方法.因此，只需在影响多个项目的单个点进行更改即可.

We are thinking to move our ci from jenkins to gitlab. We have several projects that have the same build workflow. Right now we use a shared library where the pipelines are defined and the jenkinsfile inside the project only calls a method defined in the shared library defining the actual pipeline. So changes only have to be made at a single point affecting several projects.

我想知道 gitlab ci 是否也可以这样做?据我所知，不可能在存储库之外定义 gitlab-ci.yml.是否有另一种方法来定义管道并与多个项目共享此配置以简化维护?

I am wondering if the same is possible with gitlab ci? As far as i have found out it is not possible to define the gitlab-ci.yml outside the repository. Is there another way to define a pipeline and share this config with several projects to simplify maintainance?

推荐答案

首先让我说:谢谢你提出这个问题！在我自己经常想知道这是否可行之后，它促使我(再次)寻找解决方案.我们还有大约 20 - 30 个完全相同的项目，并且有大约 400 - 500 个位置的 .gitlab-ci.yml 文件，如果一件事发生变化，每个文件都必须更改.

First let me start by saying: Thank you for asking this question! It triggered me to search for a solution (again) after often wondering if this was even possible myself. We also have like 20 - 30 projects that are quite identical and have .gitlab-ci.yml files of about 400 - 500 loc that have to each be changed if one thing changes.

所以我找到了一个可行的解决方案:

受到 Auto DevOps .gitlab-ci.yml 模板 Gitlab 自己创建的，并且他们使用一个模板作业来定义所有使用的函数和调用每个before_script来加载它们，我想出了以下设置.

Inspired by the Auto DevOps .gitlab-ci.yml template Gitlab itself created, and where they use one template job to define all functions used and call every before_script to load them, I came up with the following setup.

• 多个项目存储库(project-1、project-2) 需要一组共享的 CI 作业/功能
• 函数脚本 包含所有共享函数在单独的仓库中

• Multiple project repo's (project-1, project-2) requiring a shared set of CI jobs / functions
• Functions script containing all shared functions in separate repo

文件

所以使用 共享 ci 工作 scipt:

#!/bin/bash

function list_files {
  ls -lah
}

function current_job_info {
  echo "Running job $CI_JOB_ID on runner $CI_RUNNER_ID ($CI_RUNNER_DESCRIPTION) for pipeline $CI_PIPELINE_ID"
}

一个通用通用的.gitlab-ci.yml:

image: ubuntu:latest

before_script:
  # Install curl
  - apt-get update -qqq && apt-get install -qqqy curl
  # Get shared functions script
  - curl -s -o functions.sh https://gitlab.com/giix/demo-shared-ci-functions/raw/master/functions.sh
  # Set permissions
  - chmod +x functions.sh
  # Run script and load functions
  - . ./functions.sh

job1:
  script:
    - current_job_info
    - list_files

您可以从 项目复制粘贴您的文件-1 到 project-2 并且它将使用相同的共享 Gitlab CI 函数.

You could copy-paste your file from project-1 to project-2 and it would be using the same shared Gitlab CI functions.

这些示例非常冗长，您可以根据自己的喜好对其进行优化.

经验教训

因此，在大规模(40 多个项目)应用上述构建之后，我想分享一些经验教训，这样您就不必费力地找出方法:

So after applying the construction above on a large scale (40+ projects) I want to share some lessons learned so you don't have to find out the hard way:

• 版本(标记/发布)您共享的 ci 函数脚本.改变一件事现在可以使所有管道失败.
• 使用不同的 Docker 映像可能会导致 bash 加载函数的要求出现问题(例如，我将一些基于 Alpine 的映像用于默认具有 sh 的基于 CLI 工具的作业)
• 使用基于项目的 CI/CD 秘密变量来个性化项目的构建作业.像环境 URL 等.

• Version (tag / release) your shared ci functions script. Changing one thing can now make all pipelines fail.
• Using different Docker images could cause an issue in the requirement for bash to load the functions (e.g. I use some Alpine-based images for CLI tool based jobs that have sh by default)
• Use project based CI/CD secret variables to personalize build jobs for projects. Like environment URL's etc.

这篇关于在项目之间共享 gitlab-ci.yml的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！