在GitLab-CI中, cache
与artifacts
比较容易混淆.
其中 cache
指的是缓存, 常用于依赖安装中, 如几个jobs
都需要安装相同的依赖, 可以使用依赖
, 此时可以加快依赖的安装进度;
对于artifacts
则是将某个工件
上传到GitLab提供下载或后续操作使用, 由于每个job
启动时, 都会自动删除.gitignore
中指定的文件, 因此对于依赖安装目录, 即可以使用cache
, 也可以使用artifacts
.
两个主要有以下几个区别:
cache
不一定命中,artifacts
肯定命中, 能否使用cache
取决当当前机器是否生成过cache, artifacts则每次都会从GitLab下载- 重新安装时因为使用的是缓存, 所以很有可能不是最新的
- 特别是开发环境, 如果每次都希望使用最新的更新, 应当删除
cache
, 使用artifacts
, 这样可以保证确定的更新
4.artifacts
中定义的部分, 会自动生成, 并可以传到下面的job
中解压使用, 避免了重复依赖安装等工作 - 如果使用Docker运行Gitlab-Runner,
cache
会生成一些临时容器, 不容易清理 artifacts
可以设置自动过期时间, 过期自动删除,cache
不会自动清理artifacts
会先传到GitLab服务器, 然后需要时再重新下载, 所以这部分也可以在GitLab下载和浏览
artifacts
的依赖使用
下面是一个使用artifacts
的例子, 首先有一个安装依赖的工作, 然后工作完成后, 会将安装文件转移到后续的工作时
1 | installing-dependencies: |
如果上述过程使用cache
, 则会变成下面这样子, 注意, 此时每次都要执行composer install
这样的依赖安装工作, 即before_script
1 | cache: |
或
1 | cache: |
否则, 会出现类似 vendor not found
的问题
禁用artifacts
默认artifacts会自动在不同的stage中传输, 如果该stage中的job不需要artifacts, 则可以禁用artifacts, 以加速构建速度
1 | dependencies: [] |
注意
使用
cache
会出现一个问题, 就是缓存有可能使用上次执行该job
时的缓存, 不能保证某些文件最新