Gitee 流水线快速上手与入门
本文介绍Gitee流水线（CI/CD）的功能，旨在将代码构建并发布至服务器。文章重点提醒公开仓库中配置和日志的可见性风险，建议避免存储敏感信息。内容涵盖开通流程、基本信息与触发事件配置、任务编排（构建与部署）以及主机添加。最后以Java微服务为例，演示了完整的部署配置与脚本编写。
流水线是什么？
推荐阅读：流水线 CI/CD
Gitee流水线能干什么？
将你托管在Gitee上的代码构建发布到你的服务器上（还有制品分发，不过本篇文章不涉及这部分内容）。
使用示例
部署Java微服务项目
示例项目地址：https://gitee.com/deng-chongshuang/mall
这是一个公共仓库，因此你可以通过浏览项目根目录下.workflow中的文件，查看该项目的流水线配置：
可以看到流水线配置是以yml文件形式存储在仓库中的。
并且登录用户可以直接在流水线选项下直接查看该项目流水线的构建情况：
因此这里要强调的第一个点就是流水线的访问权限。
如果不了解Gitee流水线的访问权限，那么你就很有可能将私密性、需要保密的配置不小心暴露到公网上！
你可以在编辑某个流水线时，通过权限说明选项查看官方的具体说明：
简单总结一下：
对于私有仓库，你的流水线信息是相对安全的，因为除访客外其他成员都需要你为其授予相应角色。
对于公开仓库，你的流水线信息是人人可见的，因为其配置就存放于
.workflow目录下。对应公开仓库，流水线的变量设置也是人人可见的。
参考：仓库成员权限说明
第二点是在提示你，不要在公开仓库的流水线配置中执行或配置你需要保密的内容。
第三点是在提示你，变量在公开仓库中不具有私密性，需要保密的环境变量不要在这里进行配置！
这里的变量是指流水线的变量设置：
这里的流水线信息还包括流水线执行过程中的日志输出，公开仓库的这部分内容也是人人可见的！
因此对于公开仓库的流水线，不要有类似echo $XXX_PASSWORD的操作，这会暴露你的私密配置！
流水线的开通与费用说明
在Gitee上打开需要使用Gitee流水线的仓库，选择流水线选项。
对于首次使用流水线服务的用户Gitee会提示我们开通流水线 Gitee Go：
我们可以在靠近右上的查看更多中获取到关于Gitee Go的费用说明：
无论个人还是组织与企业，截止到本篇文章发布，其免费额度均为1000分钟每月。
通常流水线执行一次的时间在5~15分钟，即使按15分钟一次计算每月我们也能白嫖60多次，合理使用的话，对于个人开发者或小型组织是完全够用的。
点击开通Gitee Go按钮来创建我们的第一个流水线：
这里为简化教学，先选择不创建按钮，选择创建的话会为我们一次性创建三条流水线，目前是没有必要的。（注意：这里无论点击那个按钮都为为我们开通Gitee Go即Gitee的流水线服务）
创建流水线
开通后点击右上的新建流水线按钮：
流水线配置界面与基本信息配置
点击新建流水线按钮后，首先进行配置的是流水线基本信息：
通过新建流水线下方的不同选项按钮我们可以在流水线的不同配置项中快速切换。
通过中上处的图形视图/代码视图按钮切换流水线的配置方式，默认为图形视图。
我们可以在任意时刻通过右上的保存按钮保存流水线配置。
保存就是将当前流水线配置的yml文件提交到当前仓库的.workflow目录中，文件名就是流水线唯一标识。
所以在未保存流水线配置前千万不要刷新浏览器，这会丢失流水线之前未保存的配置！
并且后续推送本地代码时要先同步远程仓库，因为保存流水线会产生一次远程仓库的变更。
流水线名称配置为有一定含义的，例如：Push自动发布、手动发布、手动发布到Work服务器。
流水线唯一标识建议使用默认配置，不要动。
触发事件配置
触发事件配置支持的配置项：
这里Gitee并没有对事件监听与触发方式进行说明，笔者的理解是：当事件监听中的事件发生时，若触发方式为自动触发，则会执行后续配置——任务编排配置中的流水线；反之若触发方式为手动触发，则事件监听配置不生效，流水线只能手动执行。
建议读者对这一说法进行一定的验证。
这里我们以配置一个有Push操作则自动构建发布的流水线为例：
Push事件下的匹配规则按需选择，需要注意的是：不能仅选择Push事件，必须再额外选择：分支匹配、Tag匹配、文件/目录匹配、提交注释关键字匹配中的至少一个配置。不然Push事件监听配置无效！
任务编排
来到任务编排配置界面：
这里是流水线配置的核心，点击有+号的长方形块，添加第一个流水线阶段。
一条流水线可包含多个阶段，一个阶段可包含多个任务。阶段只是组织任务的一种形式，其主要功能是管理任务的触发方式、失败策略以及权限控制，因此你可以按触发方式、失败策略等维度来组织任务，如：将构建与测试任务编排在前置准备阶段，将部署任务编排在发布阶段；或将它们全都编排在一个阶段。
接着来讲解任务编排的界面，点击阶段名称后的编辑按钮即可编辑阶段的相关配置，选中任务即可编辑任务相关的配置，操作流程是：添加阶段、编辑阶段、选中新的任务（添加第一个任务）、编辑任务，重复上述流程即可完成流水线的任务编排。
删除阶段的按钮在编辑阶段的对话框中：
阶段名称：具有一定含义的名称
阶段唯一标识：建议默认不要动
触发方式：按需选择
失败策略：推荐选择快速失败
阶段控制权限：按需选择
参考：编排流水线
任务配置
最后来讲讲部署Java项目需要使用到的一些任务。
Gitee将支持的任务分为了：构建、测试、扫描、发布、部署、工具这几大类。
我们根据需要选择相应的任务即可。任务是可以并行执行的，也就是说如果是微服务项目我们可以并行构建多个服务，但笔者这里并不建议这样做，这会增加流水线配置的复杂性，我们可以通过更简单的配置来提高构建的效率——选择更高配置的运行资源规格。
这个配置项在构建任务（Maven 构建）的通知及高级配置中：
可供选择的配置有：1C-2G、2C-4G、4C-8G、8C-16G，最高配置是8核16G！
回到构建任务（Maven 构建）的常规配置选项：
基础信息部分的配置建议保持默认。
任务信息中的JDK版本号、Maven版本号、构建命令按需配置，其中构建命令会在仓库的根目录下执行，也就是说如果你需要单独构建某个微服务则需要通过-f参数来指定pom文件的位置。
接着讲一下暂存构建物——暂存构建物可供后续任务使用，例如部署类目下的任务。
暂存构建物是有大小限制的，一个构建物的最大存储空间为1GB左右，以我的示例项目为例：
示例项目有11个服务，每个服务打出来的jar包在150MB左右那么将它们全都通过一个构建物来收集的话那么该构建物的大小在1.6GB左右，这就超出了限制，任务会在缓存上传阶段失败！解决方案是多拆分几个构建物，示例配置：
构建好之后我们就可以部署了，因为是第一次使用流水线，我们还没有配置主机，所以显示没有可以选择的主机。我们需要先添加主机，点击主机部署任务，任务信息右侧的添加主机：
这会自动跳转到你Gitee账户的主机组管理页面，点击右上的新建主机组：
Gitee已经适配了：阿里云、腾讯云、华为云，如果你的服务器来自这几家云厂商，那么可以按其提示进行导入操作，笔者使用的服务器不在这之内所以选择自主导入。
主机组名称、主机组标识、操作系统按需设置，仓库作用域的选择需要包含你要使用Gitee流水线的仓库，示例配置如下：
配置好后点击确认，我们会回到刚刚创建的主机组管理页面：
点击右侧的添加Linux主机按钮，弹出的对话框中的选项按需配置：
复制其中的命令到服务器上执行，看到如下输出即可ctrl+c退出脚本的前台运行，此时服务已经启动完成。
如果你不主动退出，脚本也会在120秒后自动停止前台运行，期间Gitee将会监控你服务器的状态，判断是否健康，是否可用于主机部署任务。
回到刚刚新建的主机组管理页面并刷新，即可看到刚刚执行命令的服务器已经出现在主机列表中：
回到流水线配置页面选择主机部署任务，再重新选择执行主机组即可看到刚刚新添加的主机组与主机，注意不要刷新页面！因为我们还没有保存过！
接着进行部署所需文件的配置：
下载路径就是部署文件上传到你服务器的位置，建议不要用默认的，因为使用默认的~/gitee_go/deploy有个隐藏操作就是上传的文件实际会在~/gitee_go/deploy/uuid目录下，每次流水线执行其uuid都会不一样，这就导致上传的文件也会在不同的目录下，如果我们使用docker compose部署项目那就会导致运行docker compose down命令无法停止之前运行中的服务，因为它们的docker-compose.yml不在同一目录下！
文件来源选择上游构建产出，这里要注意的是选择上传文件——output是默认填充的配置，一定要修改为你实际的构建物唯一标识！
部署脚本就要结合你自己的实际情况来编写了，这里给出示例项目的部署脚本：
到此为止我们的流水线就配置完毕了，记得点击右上的保存按钮来保存流水线配置。
如果你的所有阶段的触发方式均为自动触发，那么在保存流水线后就会触发一次流水线的执行，因为流水线的保存是一次Push操作。
这时注意观察流水线的执行日志，如果流水线执行失败，则定位到具体的失败步骤，根据日志排查问题。
此外每个任务还可以配置通知，例如某一任务失败或成功后可以通过钉钉机器人来通知你，这部分内容读者可自行尝试。