GitLab Executor如何管理已安装依赖？不同Runner场景疑问

1. GitLab Executor是如何管理已安装的依赖项的？ #

GitLab Executor对依赖项的管理逻辑完全由其环境隔离机制决定：

• 核心差异在于是否复用运行环境：如果环境是一次性的，依赖仅在当前Job生命周期内有效；如果环境是持久复用的，依赖会被保留到后续Job。
• 不同类型的Executor采用不同的隔离策略，因此依赖保留规则差异很大。

2. 自行部署的GitLab Shell Executor，Job中安装的Java是否可用于下一个Job？ #

可以，但有前提：

• Shell Executor直接在Runner所在的物理/虚拟主机上执行命令，无额外环境隔离。如果Java安装在系统全局路径（比如/usr/bin、/opt这类所有用户可访问的位置），后续在同一个Runner上运行的Job都能直接调用该Java环境。
• 如果安装在Job临时目录或当前用户专属路径（比如~/.local），后续Job若使用相同用户运行也能访问，但切换用户则无法使用。
• 注意：这种共享环境的方式会导致环境污染，比如后续Job可能因依赖版本冲突出问题，不推荐长期依赖。

3. 其他类型的Runner在这方面的表现如何？ #

• Docker Executor：默认每次Job启动全新Docker容器，基于指定镜像初始化环境。Job结束后容器销毁，当前Job安装的依赖不会保留到下一个Job。如需复用依赖，可通过GitLab的cache机制缓存依赖文件，或提前将依赖打包进自定义Docker镜像。
• Kubernetes Executor：每个Job对应独立的Kubernetes Pod，Pod执行完成后销毁，环境完全隔离。依赖仅在当前Pod内有效，需通过缓存、Init容器预下载依赖或使用预装依赖的镜像来复用。
• Docker Machine Executor：和Docker Executor逻辑类似，每次Job创建全新虚拟机/容器，依赖无法跨Job保留，需借助缓存或自定义镜像。
• VirtualBox Executor：
  • 启用快照模式（默认配置）时，Job结束后VM恢复到初始快照，所有安装的依赖都会被清除。
  • 关闭快照模式时，VM状态会被保留，依赖持续存在，但这种方式会导致环境逐渐污染，仅适合特定测试场景。
• Custom Executor：依赖保留逻辑完全由自定义执行脚本决定，可选择复用现有环境保留依赖，或每次创建全新环境隔离依赖。

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