问题描述
正在将代码从自托管的GitLab迁移到Gitlab.com（云端），同时也从使用Shell构建迁移到使用Docker构建（使用Kaniko）。用户希望在构建阶段使用Gitlab.com托管的Runner，并在部署阶段使用自己的Runner。然而，由于GitLab使用Google Cloud作为其Runner，用户无法轻易将其IP加入白名单。目前遇到的问题是，缓存是在Runner级别配置的，而不是全局级别配置。因此，部署阶段的自托管Runner似乎无法访问在构建阶段生成的缓存。用户还指出，构建阶段目前不使用镜像，而是将生成的资产和Composer写入缓存中。用户想了解有哪些解决方法可尝试。
解决方案
请注意以下操作可能涉及版本差异，如有需要，请根据实际情况进行调整。
在这种情况下，您可以考虑以下解决方案来实现Gitlab.com托管的Runner和自托管Runner之间的缓存共享。
使用GitLab缓存机制
GitLab提供了一个用于缓存的机制，允许您在作业之间共享文件。您可以使用cache关键字来配置缓存策略，将构建所需的文件缓存起来，以便后续作业可以使用。
以下是如何在您的GitLab CI/CD配置中使用缓存来共享构建生成的资产和Composer的示例：
assets_build:
image: ${CI_REGISTRY_IMAGE}:${CI_COMMIT_SHA}
stage: build
# ... 其他配置 ...
cache:
key: asset_build-$CI_COMMIT_REF_NAME-build
paths:
- $BUILD_FOLDER
- /root/.pnpm-store
- node_modules
policy: pull-push
script:
- "NODE_ENV=prod ./node_modules/.bin/webpack --config webpack/webpack.config.js"
deploy_staging:
# ... 其他配置 ...
cache:
key: asset_build-$CI_COMMIT_REF_NAME-build
paths:
- $BUILD_FOLDER
policy: pull
needs:
- job: assets_build
artifacts: true
optional: true
# ... 其他配置 ...
在上述配置中，assets_build作业使用了cache关键字来缓存构建生成的文件，包括$BUILD_FOLDER、/root/.pnpm-store和node_modules。这使得在部署阶段的deploy_staging作业中，可以通过配置相同的缓存键来使用构建阶段生成的缓存。
使用Docker镜像
如果您希望在构建阶段生成的镜像可以在多个提交之间共享，您可以考虑将这个镜像推送到Docker镜像仓库，并在部署阶段使用相同的镜像。这样，您就可以跨不同的作业和提交共享构建阶段生成的镜像。
保持一致的构建环境
确保在构建阶段和部署阶段使用相同的构建环境设置，包括Docker镜像和其他必要的工具。这有助于确保在两个阶段之间共享生成的文件和资源。
使用脚本控制
如果GitLab的缓存机制无法满足您的需求，您可以编写自定义脚本来处理构建生成的文件，并在部署阶段将它们传递给自托管Runner。这可能需要更多的定制和管理，但可以根据您的具体情况进行灵活调整。
总结
在GitLab中实现Gitlab.com托管Runner和自托管Runner之间的缓存共享，您可以考虑使用GitLab的缓存机制，或者推送构建生成的镜像到Docker镜像仓库。同时，确保在构建阶段和部署阶段使用一致的构建环境，以便共享文件和资源。根据您的实际需求，您还可以使用自定义脚本来处理共享文件。
希望以上解决方案能够帮助您在GitLab中实现所需的缓存共享功能。如有任何疑问，请随时提问。