知无涯

关于如何编写GitLab流水线，.gitlab-ci.yaml文件的关键词，已经写过两期了，gitlab-ci.yaml的关键词一共有28个，分别是分别是,script, after_script, allow_failure, artifacts, before_script, cache, coverage, dependencies, environment, except, extends, image, include, interruptible, only, pages, parallel

GitLab CI文件。

最近在使用GitLab CI/CD时发现一个使用“不太顺畅”的使用场景。具体是这样的：作为一名开发者，有时需要同时负责几个前端项目的部署修复a项目的bug后需要部署到测试环境，修复b项目的bug后需要部署到测试环境。。。。。由于各种原因，这种场景的部署并非是自动部署的，需要负责人去手动创建部署流水线。比如为了给测试人员提供一个可靠，稳定的的测试环境，会采用手动部署环境。这就导致一个问题，我需要先进入A项目，点击流水线，选择对应分支，创建一个流水线。然后再进入B项目，重复以上操作。

首先需要在linux上安装 gitlab-runner然后注册一个shell作为执行器的runner该runner将应用于需要构建的项目主流水线stages: - ready - build - createdefault: tags: - shell ready_job: stage: ready script: - echo '基座准备工作' only: - masterbuild_self_job: stage: build

使用PicGo集成GitLab作为免费图库，并在Typro中使用

基于GitLab OpenAPI 开发一个仿dbt的版本管理WebIDE。支持获取项目，分支，文件树，文件内容，提交文件修改。

使用三种方案来限制开发人员的CI/CD权限。

使用VS Code的GitLab Workflow插件，进行项目的DevOps管理，将效率提升到MAX。直接在VScode中管理流水线，一键跳转到创建 Issues，MR

自从在CI/CD中集成了钉钉通知后，我就想将其做成一个通用的模块，奈何一直没搞定在curl时传递的参数写到json和变量的情况。如果在自定义通知的内容里使用变量，方案会变得更加优雅，通用，一开始我是从CI/CD的script 字符转义 入手，一直没搞定这个嵌套，嵌套，又嵌套的content传值。最近我又玩弄起了这个折磨我千百遍的问题，但这次我搜索了有关curl的命令，看到了这篇文章，https://blog.youkuaiyun.com/weixin_49114503/article/details/11967974

前言最近有几个朋友总是问我，博主，你帮我看一看我的流水线，写的规范不规范，符不符合最佳实践。博主该这么学习GitLab CI/CD，有没有什么学习路线？博主这个东西学多久才能像你一样优秀？大家都比较关心这个东西的学习成本，以及学习后的效益如何。本篇文章就来为大家解答一下这些问题。如何做到精通GitLab CI/CD？效益很多读者关心的一个问题，虽然他们没有直接问效益这个问题，但从他们的问题中我可以得出这个的一个结论。如果这个东西需要学一个月才能真正把CI/CD整套流程搞定，那我就觉还是尽早放弃比较好。

用过GitLab CI/CD的同学都知道，流水线的编写离不开GitLab CI/CD的关键词。所有业务逻辑的实现都离不开他们。比如要规定一个作业在develop分支下运行，就可以使用when关键词来是实现。如下deploy: script: echo fizz when: - develop有关这些关键词的重要性这里就不再累述，它们就像流水线的语法一样，没有它们，开发者什么都做不了。在最新的GitLab CI/CD的官方文档中，一共有35个关键词，其中有31个作业关键词分别是 aft

背景编写了几道能够考察GitLab CI/CD能力的题目，欢迎测试。 gitlab cicd 测试题1：cache与artifacts的区别？2：请说出五处定义变量的地方3：如何在流水线报错时发送通知？4：请说一些常用的预设变量5：引入外部流水线文件有那几种方式？6：提取流水线中的公共配置有哪些方式？7：如何在跨项目流水线中保证作业的运行顺序？8：如何在多个作业中传递修改后的变量值？9：如何保证安全部署，部署环境的顺序？10：如何限定某一时间的不允许部署？

导言在GitLab CI/CD中有很多官方预设的变量，这些变量极大地扩展了流水线的功能，比如有一个预设变量为 CI，在GitLab CI/CD的流水线中它的值始终为true，用于表明当前的运行环境是在CI/CD的流水线中，使用它开发者可以将一般的开发构建与流水线中的构建区分开来，从而实现不用的业务逻辑。在比如预设变量CI_COMMIT_TAG,该变量表明触发流水线的commit的tag是什么，如果是一般的分支流水线，或者合并流水线，该变量是不存在的，只有当开发者创建了一个tag，触发tag流水线时才会存在

详细讲解GitLab，GitLab Runner ，执行器之间的数据流转。

在极狐GitLab CI/CD中，我们经常用到缓存，将下载的项目依赖包缓存起来，下次自动恢复到工作目录，以此来是实现资源的最大化，加快下载与编译速度。GitLab Runner默认使用本地缓存，本地的环境是保存在安装GitLab Runner的主机上，如果你是用Docker安装，或者直接使用.rpm或 .deb 安装。这种方式不支持一条流水线跨Runner构建，即有二个依赖缓存的作业，一个作业使用的是A机器上的Runner，另一个作业使用的是B机器上的Runner，这样二个作业的缓存就不通用。这个时候最好的

背景每一个应用都在研发阶段都会有几套环境，开发环境，集成环境，测试环境，生成环境。对于不同的环境，CI/CD的处理方式可能有所不同。在GitLab CI/CD中，如果开发者想要快速查询某一个部署环境的部署历史，可以在流水线列表中，使用分支名称，触发用户，tag名称，以及流水线状态来进行搜索，如下图：但如果开发者想要查询某一个部署环境的部署历史，在这种情况下，流水线的搜索是无法满足需要的。即使开发团队规定 特定分支部署特定环境。environment关键词解决部署环境管理的问题需要使用GitLab

在GitLab CI/CD 中使用kubectl 镜像。部署应用到k8s集群中。

最近 总是有同学向我咨询一个问题，如何将流水线过程中的一些文件存放到宿主机本地，当我们的Runner使用的是Docker时再运行流水线时是在一个容器里运行的，一旦作业运行完毕，容器销毁，就什么都不剩下了，但如果我们想要保存支持，可以使用关键词，使用它可以将文件上传到极狐GitLab上。但如何我们想要将容器中文件存放到宿主机本地该怎么办那？在此处是无法使用 等从容器中拷贝文件到宿主机的指令的。本篇文章我就来给大家说一下如何将容器中的文件存放到宿主机本地。在探讨问题之前，我们先来说一下为什么会有 docker

GitLab CI/CD 系列视频教程作者，分享制作课程感悟，心路历程。

本地使用docker启动了一个GitLab又启动了一个minikube,于是把两者连接起来。由于是本地，需要在gitlab的admin中配置网络。允许接入本地ip勾上 Allow requests to the local network from web hooks and services。在本地启动minikube一直卡在 pull images 中。于是查了一下文章。发现下面两个命令很好使minikube delete --allminikube start --image-mir

如何查看旧版的GitLab CI/CD 的文档，一行Docker命令搞定 文档一次看个够Dokcer镜像 gitlab 文档各个版本的，新的，旧的，GitLab 与GitLab CI/CD的文档。启用一个docker镜像，看文档

GitLab 镜像版本 gitlab/gitlab-ce:14.1.0-ce.0GitLab Runner 镜像版本 gitlab/gitlab-runner:v14.1.0搭建此套环境是在一台32G的windows电脑上安装的。使用dokcer安装。 此外还涉及的软件Docker Desktop，WSL安装GitLab首先启动 dockcer，打开WSL打开后首先定义GitLab的持久化目录export GITLAB_HOME=/srv/gitlab然后运行安装GitLab的命令

最近在做一条流水线。是一个跨项目的流水线，涉及到各个项目的 统一分支以及各自的分支。5个应用，可以使用一个统一的变量来控制这5个应用的ref。但也可以使用一个变量单独指定某个项目的ref。一开始以为只需要定义几个变量，然后在 script中处理一下，如果没有单独指定项目的ref，就直接使用全局的ref来触发跨项目流水线那。结果在流水线中这样是不可以的。这是因为在流水线中的每个job中，都可能是不同的执行环境。可能上一个是docker，下一个是shell，下下一个是 k8s。所以如果的全局的变量

​之前在团队中分享了qiankun微服务的单镜像的部署方案， 详细解析了单镜像部署的好处，但由于单镜像部署在构建时比较复杂，如果在上线时人工地去构建镜像，将是一个非常复杂，且容易出错的事情。所以本篇文章会介绍一种使用极狐GitLab CI/CD来构建一个微服务单镜像的流水线，并应用于生产, 我称之为 aio 方案 all in one 。五个应用构建到一个docker镜像中。​之前分享的单镜像部署是在根目录创建一个child，将子应用的编译的静态资源都存放其中。 目录大致是这样的但为了兼容现有的多镜像

文章目录写在前面服务器配置环境安装安装 Docker安装 GitLab测试 GitLabGitLab Runner前端项目 CI/CD 流程的设计正式开始编写 .gitlab-ci.yml 的内容介绍 .gitlab-ci.yml镜像的使用stages 执行顺序的定义job 内容的编写在 CI/CD 中使用 SSH keys前端项目部署到阿里云OSS前端项目 CI/CD 最佳业务配置思路常见问题排查及修复相关参考链接写在前面首先感谢大家能来参加我的 Chat，能来参加的同学都是想在业余有一些其他知识的

本篇文章我将向大家演示如何在极狐GitLab 流水线中获取另一个私有仓库的代码。在流水线中获取另一个私有仓库的代码，进行构建，编译，这在跨项目和微服务架构的项目中经常使用到。特别是项目之间存在依赖关系时，该方法让你的流水线变得更加优雅。

随着软件架构不断变化，演进，项目之间，制品之间常常存在很长的调用链，存在复杂的依赖关系。这给软件构建，编译和发布带来了不小的挑战。本篇文章就教大家如何在极狐GitLab CI/CD的流水线中处理跨项目的制品依赖。提个思考题：默认地，流水线在运行过程中，下游的所有作业，都会自动获取上游的所有制品，那么为什么还需要制品依赖那？为什么还有选择性地配置当前作业下载那些制品，或不下载那些制品？

参考资料https://www.jianshu.com/p/e6363a02d437https://github.com/yarnpkg/yarn/issues/5865尝试删除 yarn.lock尽量使用同一个源yarn config set strict-ssl falseyarn config set registry https://registry.npmjs.org

各种GitLab runner执行器的区别，特性。

在服务器上安装GitLab Runner ，注册Runner，注册参数的详细解释。配置文件

在流水线中使用curl首先需要安装curl这个库，当然也可以自己构建一个镜像，直接将curl安装进去使用在流水线中使用curl的最大困难是 关于冒号 : 以及 引号"的转义。试了很久总是搞定了。由于使用的是钉钉机器人，所以会需要一个access_token 请求地址直接复制群管理中 机器人配置主要参数参数传输类型 Content-type: application/json携带的json参数 {msgtype: 'text', text: {content: 'my msg 123' }}

限定在特定时间内不允许部署环境

在gitlab ci/cd 中有两处用到corn 来配置流水线一是 设置定时流水线还有一处是 在设置 ci/cd中，首先说一下第一处，就是设置定时出发流水线 入每天晚上12点自动部署一次，可以设置一些变量。第二处 部署冻结。设置两个cron表达式， 表明在这一段时间，不允许进行部署任务。保证环境的稳定。https://en.wikipedia.org/wiki/Cron这里说一下cron的使用一共5个参数的含义常用几个表达式取值范围...

web终端控制台调试GitLab cicd流水线

之前我在优快云直播了GitLab CI/CD 入门及实践，收到了很多小伙伴的私信和赞誉，于是我开始了坚持在B站分享有关GitLab CI/CD的视频。以下是内容目录传送路。GitLab CI/CD系列教程（一）：Docker安装GitLabGitLab CI/CD系列教程（二）：Docker安装GitLab Runner GitLab CI/CD系列教程（三）：.gitlab-ci.yml的介绍与简单编写GitLab CI/CD系列教程（四）：.gitlab-ci.yml的常用关键词介绍与使用G

在开发流水线，完成部署作业时，有时需要在流水线构建环境中下载其他项目的代码，并修改推送。也可能将构建物传输到一个远程主机上，或者登录到远程主机执行一段部署脚本。都是要使用以下这段作业来完成。当然首先需要构建免密通道。

.gitlab-ci.yml关键词完整解析（二）上次我们介绍了script, image, artifacts ,tags, cache ,stage ,when ,only/except。学习了这几个关键词的用法，就不难配置一条简单的流水线。但如果要遇到更加复杂的业务场景，如微服务，流水线继承，多流水线,等复杂场景，那么只靠以上的几个用法是无法实现的。下面我就再给大家讲解其他几个更加复杂的关键词。这次讲解的关键词有before_script, after_script, dependencies

.gitlab-ci.yml关键词完整解析（一）使用GitLab自带的流水线，必须要定义流水线的内容，而定义内容的文件默认叫做.gitlab-ci.yml，使用yml的语法进行编写。目前任务关键词有28个，全局的关键词有10个，两者重叠的有很多。今天我给大家先讲解一下常用的关键词，掌握了这些关键词的用法，你可以编写逻辑严谨，易于扩展的流水线。任务的28个关键词分别是,script, after_script, allow_failure, artifacts, before_script, cach

在GitLab的CI/CD中集成华为云的OBS，实现自动部署。好处是可以配置CDN,实现资源加速。使用命令行工具obsutil。很类似阿里云的ossutil。但工具做的真的很挫啊。使用该工具的基本步骤是下载工具压缩包解压进入解压后的目录配置权限配置秘钥，凭证和OBS地址配置成功就可以操作OBS了job内容 使用obsutil将package.json上传到桶123中deploy: stage: deploy-test script: - w.

在CI/CD中演示前端三种部署方案，镜像部署，服务器部署，OSS部署这是一次总结。废话不说直接上代码.gitlab-ci.ymlimage: node:lateststages: - install - code-lint - build - deploy-test - deploy-uat - deploy-procache: paths: - node_modulesinstall: stage: install script..