Насколько большим может быть репозиторий git в Azure DevOps?
У нас есть GIT с монорепозиторием GIT-LFS, где отображается весь размер кодовой базы в GIT (с использованием git-sizer) (см. таблицу ниже, обратите внимание, что git-sizer не отображает объекты git-lfs).
| Name | Value | Level of concern |
| ---------------------------- | --------- | ------------------------------ |
| Biggest objects | | |
| * Trees | | |
| * Maximum entries [1] | 1.23 k | * |
| * Blobs | | |
| * Maximum size [2] | 900 MiB | !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! |
| | | |
| Biggest checkouts | | |
| * Number of directories [3] | 5.00 k | ** |
| * Maximum path depth [4] | 19 | * |
| * Maximum path length [5] | 222 B | ** |
| * Number of files [3] | 102 k | ** |
| * Total size of files [6] | 2.42 GiB | ** |
Проблема в том, что у нас есть очень большие наборы данных для интеграции и тестирования данных, а также модульных тестов, где данные модульного теста могут начинаться от нескольких килобайт до, возможно, 1 ГБ.
В настоящее время мы размещаем эти данные на отдельном сетевом диске, что требует, чтобы наши агенты сборки имели доступ к этому внутреннему сетевому диску. Это не позволяет нам использовать агенты сборки, размещенные в AzureDevOps.
Кроме того, проблема в том, что сетевой диск не синхронизирован с git-repo, поэтому нам нужно было установить какое-то управление версиями файлов, что время от времени дает сбой.
Теперь идея состоит в том, чтобы поместить данные в наш репозиторий git, где двоичные файлы находятся в GIT-LFS. Проблема в том, что если данные находятся в GIT-LFS, клонирование может занять вечность, и у меня нет опыта, что это означает для выборки/вытягивания/отправки в целом.
Мы также рассмотрели GIT-scalar, но я не выяснил, что именно делает git-scalar и как он может нам помочь. Я рассматривал GIT-скаляр скорее как решение OneDrive, где данные загружаются по требованию.
Другой вопрос: может ли репозиторий Azure расти неограниченно. Я читал что-то около 250 ГБ.
Есть ли какой-нибудь опыт того, как это можно сделать?
Ответы 1
В репозитории Azure существует ограничение в 250 ГБ. Согласно ограничениям Git,
Размер репозитория не должен превышать 250 ГБ.
Если вам необходимо хранить большие файлы, рассмотрите возможность использования Git LFS (хранилище больших файлов), которое предназначено для эффективной обработки больших файлов, сохраняя их вне основного репозитория и сохраняя только ссылки на них внутри репозитория. Такой подход помогает поддерживать производительность и управляемость вашего репозитория Git.
Для «Проблема в том, что если данные находятся в GIT-LFS, клонирование может занять вечность»,
Если вы используете агенты, размещенные на MS, вы будете получать новый агент при каждом запуске конвейера. Если ваши файлы большие, независимо от того, находятся они в GIT-LFS или нет, время оформления заказа будет увеличиваться по мере увеличения размера файлов. В конвейере Azure вы можете использовать задачу checkout для извлечения большого файла с помощью параметра lfs.
steps:
- checkout: string # Required as first property. Configures checkout for the specified repository.
clean: true | false # If true, run git clean -ffdx followed by git reset --hard HEAD before fetching.
fetchDepth: string # Depth of Git graph to fetch.
fetchFilter: string # Filter Git history.
fetchTags: string # Set to 'true' to sync tags when fetching the repo, or 'false' to not sync tags. See remarks for the default behavior.
lfs: string # Set to 'true' to download Git-LFS files. Default is not to download them.
persistCredentials: string # Set to 'true' to leave the OAuth token in the Git config after the initial fetch. The default is not to leave it.
submodules: string # Set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules. Default is not to fetch submodules.
path: string # Where to put the repository. The root directory is $(Pipeline.Workspace).
workspaceRepo: true | false # When true, use the repository root directory as the default working directory for the pipeline. The default is false.
condition: string # Evaluate this condition expression to determine whether to run this task.
continueOnError: boolean # Continue running even on failure?
displayName: string # Human-readable name for the task.
target: string | target # Environment in which to run this task.
enabled: boolean # Run this task when the job runs?
env: # Variables to map into the process's environment.
string: string # Name/value pairs
name: string # ID of the step.
timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.
retryCountOnTaskFailure: string # Number of retries if the task fails.
lfs: установите значение «true», чтобы загружать файлы Git-LFS. По умолчанию их не скачивать.
Ибо «и у меня нет опыта, что это означает для извлечения/вытягивания/нажатия в целом».
Рекомендуется просмотреть git-lfs и эту вики, чтобы понять GIT-LFS.
Кроме того, см. Управление большими файлами и их хранение в Git для получения дополнительной информации об управлении большими файлами в репозитории Azure.
Одной из особенностей git скаляра является частичное клонирование. По умолчанию Scalar сокращает ваш рабочий каталог только до файлов в корне репозитория. Вы можете использовать git sparse-checkout set, чтобы установить список каталогов для вашей разреженной проверки. Тогда будут загружены только ваши целевые файлы/папка. Подробности смотрите в этом документе.
Спасибо за объяснение. Я знаю о разреженной проверке, но ее нужно делать вручную через командную строку. Если активирован git scalara, помогает ли он мне автоматически загружать файлы, когда они необходимы? Я не мог видеть этого из документов.
«Если git scalara активирован, помогает ли это мне автоматически загружать файлы, когда они требуются?» — если вы используете git scalar на своем локальном компьютере или локальный агент, это может сработать (вы можете проверить это на своей стороне, Я не проверял), но если вы используете агент, размещенный на MS, боюсь, он не сработает. Поскольку вы получаете совершенно нового агента каждый раз, когда запускаете конвейер.
Хорошо. Я согласен, что это может не работать на хост-агентах MS, но это будет нормально. Я приму это как ответ.
Спасибо за подсказку. Для больших файлов мы уже используем git-lfs. Как вы сказали, это все или ничего, даже если вам это не нужно для модульных тестов. Поэтому вопрос также в том, при использовании git-scalar загружаются ли необходимые данные по требованию?