GitLab CI流水线中build生成的packer文件为何在deploy阶段被删除

• 第一类触发问题：YAML配置语法失效导致制品传递中断
  你流水线配置里所有列表项前的破折号使用了全角长破折号“–”，不符合YAML标准语法。这种问题不会直接抛出配置解析错误，只会被YAML解析器当成普通文本节点处理——意味着你在artifacts.paths下声明的packer路径根本没有被识别为有效的制品匹配规则。
  补充说明：GitLab CI的每个作业运行在独立的临时工作目录中，不同作业之间的文件不会自动共享，必须通过artifacts机制显式声明需要跨作业传递的文件，才会被打包传递。配置失效后，build阶段生成的所有文件（包括packer可执行文件、压缩包）都没有被打包成制品，自然无法被deploy阶段访问到。
• 第二类触发问题：deploy阶段的默认清理逻辑
  GitLab Runner执行每个作业的固定初始化流程为：检出指定分支的Git代码 → 解压上一阶段传递的制品文件 → 执行git clean -ffdx，递归删除所有未被Git追踪的文件，保证作业运行在无残留干扰的纯净环境中。
  因为制品传递链路已经断开，deploy阶段启动时，工作目录里只有Git仓库本身的代码文件，没有任何build阶段生成的内容。你在日志里看到的Removing packer.zip、Removing packer/packer操作，本质是Runner在清理上次作业运行遗留的临时文件，并不是本次build阶段生成的文件被意外删除。
  清理流程结束后，工作目录中不存在对应的packer可执行文件，自然会触发./packer: No such file or directory的报错。

• 将所有配置块里的全角长破折号“–”替换为YAML要求的半角短横“-”，确保artifacts.paths: packer的声明可以被正确识别，让build阶段生成的packer目录自动作为制品跨阶段传递。
• 配置修正完成后，可以在build作业的详情页验证制品打包结果：如果能看到打包上传的packer目录，说明跨阶段文件传递链路正常。
• 原有脚本逻辑不需要调整：build阶段的下载压缩包、解压文件、给可执行文件赋权的操作逻辑本身没有问题，只要制品传递正常，deploy阶段执行packer构建命令时就能找到对应的可执行文件。

内容的提问来源于stack exchange，提问作者mandelbrotofsilence