Gitlab в настоящее время не поддерживает многоэтапную загрузку на S3, поэтому он может обрабатывать только кэши размером до 5 ГБ.Но, прежде чем продолжить чтение, ознакомьтесь с предложением по этой проблеме / функции по этой теме!
Поэтому я создал себе грязный обходной путь, но будьте осторожны!Любой, кто запускает сборку на этом средстве запуска, может просто напечатать AWS AccessKey / SecretKey в журнал сборки!
По сути, я просто повторил извлечение и извлечение кеша из S3 и выполняю это вручную до и послемой buildjob.
В моем gitlab runner 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
необходимо выбрать размер частей кэша, и если он выберет слишком маленький размер для загрузки, он превысит максимальный лимит частей многочастной загрузки.В моем примере использовалось 7 ГБ.
Мой .gitlab-ci.yaml
теперь выглядит так:
build:
script:
- ./download_cache.sh
- ./build.sh
- ./upload_cache.sh