我正在使用GitLab CI。
在构建阶段,我有2个工作以不同的方式构建我的应用程序。 2个作业为分支上传了一个缓存。我使用编译的源代码在测试阶段启动一些测试。
build:
stage: build
script:
- ./gradlew build --build-cache --quiet
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- "*/build"
build_with_different_conf:
stage: build
script:
- ./gradlew buildDiff --build-cache --quiet
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- "*/build"
Test:
stage: test
script:
- ./gradlew test --build-cache
在我的示例中,build_with_different_conf作业需要更多时间才能完成。
我的问题是:最后完成的构建作业是上载缓存并替换第一个构建作业中的缓存吗,还是它与先前的作业合并文件?
谢谢。
答案 0 :(得分:1)
据我了解,您正在将全局缓存用于gradle依赖项。 比您想要某种作业来缓存作业。
我或多或少会这样。
stages:
- build
- test
cache:
paths:
- <your_gradle_cache>
build_classes:
stage: build
script:
- ./gradlew build --build-cache --quiet
artifacts:
expire_in: 1d
paths:
- <your_build_dir>
build_war:
stage: build
dependencies:
- build_classes
script:
- ./gradlew buildDiff --build-cache --quiet
artifacts:
expire_in: 1w
paths:
- <path_to_your_war>
test_classes:
stage: test
dependencies:
- build_war
script:
- ./gradlew test --build-cache
test_war:
stage: test
dependencies:
- build_war
script:
- test # some kind of test to assure your war is in good condition
在此配置中:
build_classes --[.classes]--> build_war -> [.war]
| |
[.classes] [.war]
| |
V V
test_classes test_war
PS。不要忘记,您可以使用shell
(或任何其他运行者的操作系统)进行调试,了解有关此内容的更多信息。您可以将ls -la
放在各处。
答案 1 :(得分:0)
build:
stage: build
同一阶段的作业并行运行。
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- "*/build"
缓存文件由cache:key
管理。这意味着,如果您为不同的作业使用相同的cache:key
,则即使您定义了不同的cache.zip
,它们也会在作业之间共享相同的cache:paths
文件。如果您使用相同的密钥,但使用不同的路径,则您的缓存将无效,因为每个作业都会覆盖具有不同路径内容的cache.zip
文件。
在您的情况下,您在不同的工作中使用相同的cache:key
。
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- "*/build"
这意味着上一个完成的作业将覆盖cache.zip
文件,而不是合并文件,将用于下一个作业以及定义了相同键的后续管道作业。
奖金:
Test:
stage: test
script:
- ./gradlew test --build-cache
还请注意,如果此作业需要存在*/build
目录内容,则必须小心并更好地使用工件。缓存并不总是存在,而是作为尽力而为的方式提供的。