Question

我将yocto项目配置为使用自动缩放的gitlab-runner在AWS上运行，现在我注意到，随着项目的发展，缓存每次都无法上传。

Uploading cache.zip to https://build-yocto.s3.amazonaws.com/project/default 
WARNING: Retrying...                               
Uploading cache.zip to https://build-yocto.s3.amazonaws.com/project/default 
FATAL: Received: 400 Bad Request                   
Failed to create cache

缓存中包含sstate-cache目录，以加快重建速度，该重建方法从一开始就非常有用，但是现在失败了，因为（至少是我的结论），sstate-目录已增长到10GB以上。

我看到S3可以进行分段上传，但是找不到gitlab-runner的任何选项来启用此功能。

该问题是否有解决方法？像预处理状态缓存并上传多个缓存一样？

Answer 1

Gitlab当前不支持分段上传到S3，因此它只能处理最大5GB的缓存。但是在继续阅读之前，请先查看this issue/feature proposal的相关主题！

因此，我为自己构建了一个肮脏的解决方法，但被警告！在该运行器上运行构建的任何人都可以简单地将AWS AccessKey / SecretKey打印到构建日志中！

基本上，我只是复制了S3中缓存的拉入和推送，并在构建作业之前和之后手动进行了操作。

在gitlabRunner config.toml中，我在[[runners]]部分添加了以下行：

environment = ["AWS_ACCESS_KEY_ID=<AccessKey>", "AWS_SECRET_ACCESS_KEY=<SecretKey>", "AWS_DEFAULT_REGION=<region>", "AWS_DEFAULT_OUTPUT=<json,text or table>"]

这样，可以设置evrionment变量，aws cli可以满足一切需求。

在我的Dockerfile中，我需要添加以下软件包：

# Install AWS CLI and tools
RUN apt-get install -y awscli tar pigz

下载脚本：

#!/bin/bash
mkdir <path to cache>
aws s3 cp s3://<bucket name>/cache - | pigz -dc | tar -xf - -C <path to cache>

上传脚本：

#!/bin/bash
tar cf - -C <path to cache> . | pigz | aws s3 cp - s3://<bucket name>/cache --expected-size 7516192768

--expected-size是高速缓存的近似大小。这是必需的，因为aws cp s3需要选择缓存部分的大小，如果选择的大小太小而不适合上载，则将超过分段上传的最大部分限制。我的示例使用了7GB。

我的.gitlab-ci.yaml现在看起来像这样：

build:
  script:
    - ./download_cache.sh
    - ./build.sh
    - ./upload_cache.sh

Gitlab：如何使用带有S3的自动缩放运行器处理大于5GB的缓存

1 个答案: