{"meta":{"title":"Оптимизация создания запросов на вытягивание обновлений версий Dependabot","intro":"Узнайте, как оптимизировать и эффективно управлять pull-запросами Dependabot .","product":"Безопасность и качество кода","breadcrumbs":[{"href":"/ru/code-security","title":"Безопасность и качество кода"},{"href":"/ru/code-security/tutorials","title":"Tutorials"},{"href":"/ru/code-security/tutorials/secure-your-dependencies","title":"Защита зависимостей"},{"href":"/ru/code-security/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates","title":"Оптимизация создания PR"}],"documentType":"article"},"body":"# Оптимизация создания запросов на вытягивание обновлений версий Dependabot\n\nУзнайте, как оптимизировать и эффективно управлять pull-запросами Dependabot .\n\nПо умолчанию Dependabot открывается новый pull request для обновления каждой зависимости. При включении обновлений системы безопасности новые запросы на вытягивание открываются при обнаружении уязвимой зависимости. При настройке обновлений версий для одной или нескольких экосистем новые запросы на вытягивание открываются при наличии новых версий зависимостей с частотой, определенной `dependabot.yml` в файле.\n\nЕсли в вашем проекте много зависимостей, вы можете столкнуться с очень большим количеством Dependabot pull-запросов для проверки и объединения, что быстро становится сложно в управлении.\n\nСуществует несколько опций настройки, которые можно реализовать для оптимизации Dependabot pull request-запросов на обновление с вашими процессами, например:\n\n* **Управление частотой**Dependabot проверок новых версий ваших зависимостей с помощью `schedule`.\n* **Приоритет значимых обновлений** с `groups`помощью .\n\n## Управление частотой и временем обновления зависимостей\n\n```\n          Dependabotзапускает проверки обновлений версий на частоте, заданной вами в конфигурационном файле, где необходимое поле `schedule.interval`, , должно быть установить в `daily`, `weekly`, `semiannually``quarterly``yearly``monthly`или `cron` (см. ).[`cronjob`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#cronjob)\n```\n\nПо умолчанию Dependabot балансирует свою нагрузку, назначая случайное время для проверки и подъёма pull запросов на обновления зависимостей.\n\nТем не менее, чтобы уменьшить отвлекающий фактор или упорядочить время и ресурсы для просмотра и решения обновлений версий, может оказаться полезным изменить частоту и время. Например, вы можете предпочесть Dependabot проводить еженедельные проверки обновлений не ежедневно, и в это время, чтобы pull requests были подняты до сессии триажа вашей команды.\n\n### Изменение частоты и времени обновления зависимостей\n\nВы можете использовать `schedule` их с комбинацией опций для изменения частоты и времени Dependabot проверки обновлений версий.\n\nПример `dependabot.yml` файла ниже изменяет конфигурацию npm, чтобы указать, что Dependabot должна проверять обновления версий зависимостей npm каждый вторник в 02:00 по японскому стандартному времени (UTC +09:00).\n\n```yaml copy\n# `dependabot.yml` file with\n# customized schedule for version updates\n\nversion: 2\nupdates:\n  # Keep npm dependencies up to date\n  - package-ecosystem: \"npm\"\n    directory: \"/\"\n    # Check the npm registry every week on Tuesday at 02:00 Japan Standard Time (UTC +09:00)\n    schedule:\n      interval: \"weekly\"\n      day: \"tuesday\"\n      time: \"02:00\"\n      timezone: \"Asia/Tokyo\"\n```\n\nСм. также [расписание](/ru/code-security/dependabot/working-with-dependabot/dependabot-options-reference#schedule-).\n\n### Настройка периода охлаждения для обновлений зависимостей\n\nВы можете использовать  `cooldown` их с комбинацией опций для контроля момента, когда Dependabot создаётся pull request на **обновления версий**, но не **для обновлений безопасности**.\n\nВ приведенном ниже примере `dependabot.yml` файла показан период охлаждения, применяемый к зависимостям `requests`, `numpy`а также префикс `pandas` с именем или `django`, но не к зависимостям `pandas` ( точному совпадению), который исключается из **списка исключений** .\n\n```yaml copy\nversion: 2\nupdates:\n  - package-ecosystem: \"pip\"\n    directory: \"/\"\n    schedule:\n      interval: \"daily\"\n    cooldown:\n      default-days: 5\n      semver-major-days: 30\n      semver-minor-days: 7\n      semver-patch-days: 3\n      include:\n        - \"requests\"\n        - \"numpy\"\n        - \"pandas*\"\n        - \"django\"\n      exclude:\n        - \"pandas\"\n```\n\n* Количество дней охлаждения должно составлять от 1 до 90.\n* Максимально допустимое ограничение элементов в `include` списках и `exclude` списках, с которыми можно использовать `cooldown`, составляет 150.\n\n> \\[!NOTE]\n> Чтобы рассмотреть **все зависимости** для периода охлаждения, можно:\n>\n> * Опустите `include` параметр, который применяет прохладу ко всем зависимостям.\n> * ```\n>           `\"*\"` Используйте для `include` применения параметров охлаждения ко всему.\n>   ```\n\nРекомендуется **использовать только `exclude` для** исключения **определенных зависимостей** из параметров охлаждения.\n\nSemVer поддерживается для большинства диспетчеров пакетов. Обновления новых версий для зависимостей в прохладном меню откладываются следующим образом:\n\n* Основные обновления: задержка в 30 дней (`semver-major-days: 30`).\n* Незначительные обновления: задержка на 7 дней (`semver-minor-days: 7`).\n* Обновления исправлений: отложено на 3 дня (`semver-patch-days: 3`).\n\nСм. также [`cooldown`](/ru/code-security/dependabot/working-with-dependabot/dependabot-options-reference#cooldown-).\n\n## Приоритет значимых обновлений\n\n### Группирование связанных зависимостей вместе\n\nМожно использовать `groups` для консолидации обновлений для нескольких зависимостей в одном запросе на вытягивание. Это помогает сосредоточить время проверки на более высокий риск обновлений и свести к минимуму время, затраченное на просмотр дополнительных обновлений версий. Например, можно объединить обновления для дополнительных обновлений или исправлений для зависимостей разработки в один запрос на вытягивание и иметь выделенную группу для обновлений безопасности или версий, влияющих на ключевую область базы кода.\n\nНеобходимо настроить группы на отдельную экосистему пакетов, а затем создать несколько групп для каждой экосистемы пакетов с помощью сочетания критериев:\n\n* Dependabot Тип обновления: `applies-to`\n* Тип зависимости: `dependency-type`.\n* Имя зависимости: `patterns` и `exclude-patterns`\n* Уровни семантического управления версиями: `update-types`\n\nЧтобы просмотреть все поддерживаемые значения для каждого критерия, см. раздел [`groups`](/ru/code-security/dependabot/working-with-dependabot/dependabot-options-reference#groups--).\n\nВ приведенных ниже примерах представлено несколько различных методов создания групп зависимостей с помощью условий.\n\n### Пример 1. Три группы обновлений версий\n\nВ этом примере `dependabot.yml` файл:\n\n* Создает три группы, называемые \"\", \"`production-dependencies``development-dependencies`\", \"\" и \"`rubocop`\".\n* Использует `patterns` и `dependency-type` включает зависимости в группу.\n* Используется `exclude-patterns` для исключения зависимостей (или нескольких зависимостей) из группы.\n\n```yaml\nversion: 2\nupdates:\n  # Keep bundler dependencies up to date\n  - package-ecosystem: \"bundler\"\n    directory: \"/\"\n    schedule:\n      interval: \"weekly\"\n    groups:\n      production-dependencies:\n        dependency-type: \"production\"\n      development-dependencies:\n        dependency-type: \"development\"\n        exclude-patterns:\n          - \"rubocop*\"\n      rubocop:\n        patterns:\n          - \"rubocop*\"\n```\n\nВ результате:\n\n* Обновления версий группируются по типу зависимостей.\n* Зависимости разработки, соответствующие шаблону `rubocop*` , исключаются из `development-dependencies` группы.\n* Вместо этого сопоставления зависимостей разработки `rubocop*` будут включены в группу `rubocop` . Из-за упорядочения соответствие зависимостей `rubocop*` рабочей среды будет включено в группу `production-dependencies` .\n* Кроме того, все группы по умолчанию применяются только к обновлениям версий, так как `applies-to` ключ отсутствует.\n\n### Пример 2. Группированные обновления с исключенными зависимостями\n\nВ этом примере `dependabot.yml` файл:\n\n* Создает группу с именем \"`support-dependencies`\", в рамках настраиваемой конфигурации пакета.\n* Использует `patterns` это сопоставление с именем зависимости (или несколькими зависимостями) для включения зависимостей в группу.\n* Использует `exclude-patterns` это сопоставление с именем зависимости (или нескольких зависимостей), чтобы исключить зависимости из группы.\n* Применяет группирование только к обновлениям версий, так как `applies-to: version-updates` используется.\n\n```yaml\nversion: 2\nupdates:\n  # Keep bundler dependencies up to date\n  - package-ecosystem: \"bundler\"\n    directories:\n      - \"/frontend\"\n      - \"/backend\"\n      - \"/admin\"\n\n    schedule:\n      interval: \"weekly\"\n    # Create a group of dependencies to be updated together in one pull request\n    groups:\n      # Specify a name for the group, which will be used in pull request titles\n      # and branch names\n      support-dependencies:\n        # Define patterns to include dependencies in the group (based on\n        # dependency name)\n        applies-to: version-updates # Applies the group rule to version updates\n        patterns:\n          - \"rubocop\" # A single dependency name\n          - \"rspec*\"  # A wildcard string that matches multiple dependency names\n          - \"*\"       # A wildcard that matches all dependencies in the package\n                      # ecosystem. Note: using \"*\" may open a large pull request\n        # Define patterns to exclude dependencies from the group (based on\n        # dependency name)\n        exclude-patterns:\n          - \"gc_ruboconfig\"\n          - \"gocardless-*\"\n```\n\nВ результате:\n\n* Большинство зависимостей для пакета объединяются в `support-dependencies` группу из-за шаблона подстановочного знака (\"\\*\") помимо\n* Зависимости, которые соответствуют `gc_ruboconfig` и `gocardless-*` исключены из группы, и Dependabot продолжает создавать однократные запросы на вытягивание для этих зависимостей. Это может быть полезно, если обновления для этих зависимостей необходимо проверить с более тщательной проверкой.\n* Для `support-dependencies`параметра Dependabot вызываются только запросы на вытягивание обновлений версий.\n\n### Пример 3. Отдельные запросы на вытягивание основных обновлений и сгруппированы для дополнительных или исправлений\n\nВ этом примере `dependabot.yml` файл:\n\n* Создает группу с именем \"`angular`\".\n* Использует `patterns` это сопоставление с именем зависимости для включения зависимостей в группу.\n* Используется `update-type` только для включения `minor` или `patch` обновления в группу.\n* Применяет группирование только к обновлениям версий, так как `applies-to: version-updates` используется.\n\n```yaml\nversion: 2\nupdates:\n  - package-ecosystem: \"npm\"\n    directory: \"/\"\n    schedule:\n      interval: \"weekly\"\n    groups:\n      # Specify a name for the group, which will be used in pull request titles\n      # and branch names\n      angular:\n        applies-to: version-updates\n        patterns:\n          - \"@angular*\"\n        update-types:\n          - \"minor\"\n          - \"patch\"\n```\n\nВ результате:\n\n* Dependabot создаст сгруппированные запросы на вытягивание для всех зависимостей Angular, которые имеют дополнительное или исправление обновления.\n* Все основные обновления будут по-прежнему вызываться в виде отдельных запросов на вытягивание.\n\n### Пример 4. Сгруппированные запросы на вытягивание для дополнительных обновлений или исправлений и нет запросов на вытягивание для основных обновлений\n\nВ этом примере `dependabot.yml` файл:\n\n* Создает две группы с именем \"`angular`\" и \"`minor-and-patch`\".\n* Используется `applies-to` таким образом, что первая группа применяется только к обновлениям версий, а вторая группа применяется только к обновлениям системы безопасности.\n* Используется `update-type` только для включения `minor` или `patch` обновления для обеих групп.\n* `ignore` Использует условие для исключения обновлений версий `major` `@angular*` пакетов.\n\n```yaml\nversion: 2\nupdates:\n  # Keep npm dependencies up to date\n  - package-ecosystem: \"npm\"\n    directory: \"/\"\n    schedule:\n      interval: \"weekly\"\n    groups:\n      angular:\n        applies-to: version-updates\n        patterns:\n          - \"@angular*\"\n        update-types:\n          - \"minor\"\n          - \"patch\"\n      minor-and-patch:\n        applies-to: security-updates\n        patterns:\n          - \"@angular*\"\n        update-types:\n          - \"patch\"\n          - \"minor\"\n    ignore:\n      - dependency-name: \"@angular*\"\n        update-types: [\"version-update:semver-major\"]\n```\n\nВ результате:\n\n* Обновления дополнительных и исправлений для зависимостей Angular группируются в один запрос на вытягивание.\n* Дополнительные обновления безопасности и исправления для зависимостей Angular также группируются в один запрос на вытягивание.\n* Dependabot не будет автоматически открывать запросы на вытягивание основных обновлений для Angular.\n\n### Группировка обновлений между каталогами в монорепо\n\nЕсли вы управляете монорепозитором с несколькими каталогами, разделяющими общие зависимости, вы можете уменьшить количество pull requests на обновления версий, группируя обновления по именам зависимостей во всех каталогах.\n\nКогда вы настроите Dependabot мониторинг нескольких каталогов и включите группировку по имени зависимости, Dependabot будет:\n\n* Создайте один pull request для каждого обновления зависимостей, затрагивающий несколько каталогов\n* Обновите одну и ту же зависимость до одной версии для всех каталогов за одну операцию\n* Сократьте количество pull request, которые нужно просматривать\n* Минимизируйте затраты на CI/CD, выполняя тесты один раз вместо каждого каталога\n\nДополнительные сведения см. в статье [`group-by`](/ru/code-security/reference/supply-chain-security/dependabot-options-reference#group-by-groups).\n\nЭтот пример конфигурации группирует обновления по имени зависимостей в `/frontend`каталогах , `/admin-panel`, и `/mobile-app` . Если `lodash` требуется обновление во всех трёх каталогах, Dependabot создаётся один pull request под названием «Bump lodash in monorepo-dependencies group», который обновляется `lodash` во всех трёх местах.\n\n```yaml\nversion: 2\nupdates:\n  - package-ecosystem: \"npm\"\n    directories:\n      - \"/frontend\"\n      - \"/admin-panel\"\n      - \"/mobile-app\"\n    schedule:\n      interval: \"weekly\"\n    groups:\n      monorepo-dependencies:\n        group-by: dependency-name\n```"}