我们使用gitlab ci和共享运行器来进行持续集成。对于每个构建,跑步者下载大量的maven工件。
有没有办法配置gitlab ci来缓存这些工件,这样我们可以通过阻止一遍又一遍地下载相同的工件来加快构建过程?
答案 0 :(得分:43)
Gitlab CI允许您在每个作业或构建基础上定义某些路径,这些路径包含应在构建之间缓存的数据(有关详细信息,请参阅here)。结合khmarbaise的建议,这可以用于缓存多个构建之间的依赖关系。
缓存构建中所有作业依赖项的示例:
cache:
paths:
- .m2/
variables:
MAVEN_OPTS: "-Dmaven.repo.local=.m2"
maven_job:
script:
- mvn clean install
答案 1 :(得分:8)
根据GitLab's issue tracker上的对话,我设法更改了Maven本地存储库路径并将其放入./.m2/repository/
目录,然后我们将在运行之间通过将此全局块添加到CI配置:
cache:
paths:
- ./.m2/repository
# keep cache across branch
key: "$CI_BUILD_REF_NAME"
不幸的是,根据this StackOverflow answer,maven本地存储库路径只能在-Dmaven.repo.local
的每次运行中设置,或者通过编辑settings.xml
来设置,这在gitlab中是一项繁琐的任务。 -ci配置脚本。一个选项是使用默认的Maven选项设置变量并将其传递给每次运行。
此外,本地Maven存储库是当前目录的子级是至关重要的。出于某种原因,将它放在/cache
或/builds
中并不适合我,即使GitLab的某人声称应该这样做。
Maven + Java的工作gitlab-ci.yml
配置文件示例:
image: maven:3-jdk-8
variables:
MAVEN_OPTS: "-Djava.awt.headless=true -Dmaven.repo.local=./.m2/repository"
MAVEN_CLI_OPTS: "--batch-mode --errors --fail-at-end --show-version"
cache:
paths:
- ./.m2/repository
# keep cache across branch
key: "$CI_BUILD_REF_NAME"
stages:
- build
- test
- deploy
build-job:
stage: build
script:
- "mvn clean compile $MAVEN_CLI_OPTS"
artifacts:
paths:
- target/
unittest-job:
stage: test
dependencies:
- build-job
script:
- "mvn package $MAVEN_CLI_OPTS"
artifacts:
paths:
- target/
integrationtest-job:
stage: test
dependencies:
- build-job
script:
- "mvn verify $MAVEN_CLI_OPTS"
artifacts:
paths:
- target/
deploy-job:
stage: deploy
artifacts:
paths:
- "target/*.jar"
答案 2 :(得分:5)
您可以将缓存文件夹添加到gitlab-ci runner配置并将其传递给maven。
<强> /etc/gitlab-runner/config.toml 强>
[[runners]]
...
[runners.docker]
...
volumes = ["/cache", "/.m2"]
...
<强> .gitlab-ci.yml 强>
variables:
MAVEN_OPTS: "-Dmaven.repo.local=/.m2"
build:
script:
- mvn package
答案 3 :(得分:4)
被接受的答案对我没有帮助。
正如 zlobster 所述,GitLab的这些人拥有令人惊叹的repository,在这里您可以找到用于Maven项目的.gitlab-ci.yml
文件的正确示例。
基本上,您需要这些行:
cache:
paths:
- .m2/repository
请记住,如果您决定为某个作业添加本地缓存,则上面添加的全局缓存将被替换。有关here的更多信息。
答案 4 :(得分:1)
如果您将kubernetes用作gitlab-runner的执行器,则还可以使用Maven缓存。我选择在具有k8s PV的NFS上具有持久性缓存(但gitlab-runner支持其他卷类型)。由于NFS提供了持久性,因此以下配置未使用cache gitlab功能。
1)在群集上创建一个PersistentVolume,在此处使用NFS(适应您的持久层和您的选项):
apiVersion: v1
kind: PersistentVolume
metadata:
name: gitlabrunner-nfs-volume
spec:
capacity:
storage: 10Gi
mountOptions:
- nolock
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Recycle
nfs:
path: /gitlabrunner
server: 1.2.3.4
2)引用PV以在流道吊舱中以体积获取索赔:
[[runners.kubernetes.volumes.pvc]]
name = "pvc-1"
mount_path = "/path/to/mount/point1"
注意(03/09/18):这些参数的命令行选项尚不存在。有一个开放的issue。
3)为gitlab-runner缓存指定相同的路径:
[[runners]]
executor = "kubernetes"
# ...
cache_dir = "/path/to/mount/point1"
或
--cache-dir "/path/to/mount/point1"
以交互模式
4)使用-Dmaven.repo.local
选项中的“ / path / to / mount / point1”目录
答案 5 :(得分:0)
我能够使用主机卷共享我的.m2
存储库目录。这还具有共享我的settings.xml
文件(并非每个人都想要)的优点。我发现这比使用提到的cache
解决方案要快。
[[runners]]
[runners.docker]
volumes = ["/home/<user>/.m2:/root/.m2"]
答案 6 :(得分:0)
还有另一种方法。请勿使用gitlab缓存并使用自定义(每个项目)的Docker映像。
一些细节:
首先,您需要创建一个maven docker映像,其中显示了项目依赖项所需的全部(或大部分)。将其发布到注册表(gitlab有一个注册表),并将其用于运行maven的任何作业。
要创建这样的图像,我通常会在CI中手动创建一个附加作业。您需要在初始阶段以及对项目依赖项进行大量修改时触发它。
可以在这里找到工作示例:
https://gitlab.com/alexej.vlasov/syncer/blob/master/.gitlab-ci.yml -该项目正在使用准备好的图像,并且它还有准备工作。
https://gitlab.com/alexej.vlasov/maven/blob/master/Dockerfile -dockerfile运行maven并下载依赖项一次。
优点:
答案 7 :(得分:0)
使用CI_PROJECT_DIR变量(克隆存储库和运行作业的完整路径)时,无需在变量部分声明MAVEN_OPTS
cache:
key: maven-cache
paths:
- $CI_PROJECT_DIR/.m2/