{"meta":{"title":"Otimizando a criação de pull requests para atualizações de versão do Dependabot","intro":"Saiba como simplificar e gerenciar com eficiência suas Dependabot solicitações de pull.","product":"Qualidade de segurança e código","breadcrumbs":[{"href":"/pt/code-security","title":"Qualidade de segurança e código"},{"href":"/pt/code-security/tutorials","title":"Tutorials"},{"href":"/pt/code-security/tutorials/secure-your-dependencies","title":"Proteger suas dependências"},{"href":"/pt/code-security/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates","title":"Otimizar a criação de PR"}],"documentType":"article"},"body":"# Otimizando a criação de pull requests para atualizações de versão do Dependabot\n\nSaiba como simplificar e gerenciar com eficiência suas Dependabot solicitações de pull.\n\nPor padrão, Dependabot abre uma nova solicitação de pull para atualizar cada dependência. Quando você habilita atualizações de segurança, novas pull requests são abertas quando uma dependência vulnerável é encontrada. Quando você configura atualizações de versão para um ou mais ecossistemas, novas pull requests são abertas quando novas versões de dependências estão disponíveis, com a frequência definida no arquivo `dependabot.yml`.\n\nSe o projeto tiver muitas dependências, você poderá descobrir que tem um número muito grande de solicitações de Dependabot pull para revisar e mesclar, o que pode se tornar difícil de gerenciar rapidamente.\n\nHá algumas opções de personalização que você pode implementar para otimizar Dependabot a atualização de solicitações de pull para alinhá-las com seus processos, como:\n\n* ```\n            **Controlar a frequência** com que Dependabot verifica se há versões mais recentes das suas dependências com `schedule`.\n  ```\n* **Priorizar atualizações significativas** com `groups`.\n\n## Controlar a frequência e os intervalos das atualizações de dependência\n\n```\n          Dependabotexecuta suas verificações de atualizações de versão em uma frequência definida por você no arquivo de configuração, onde o campo necessário, `schedule.interval`deve ser definido como`daily`, `weekly`, , `monthly`, `quarterly`, `semiannually`ou `yearly``cron` (consulte [`cronjob`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#cronjob)).\n```\n\nPor padrão, Dependabot equilibra sua carga de trabalho atribuindo um tempo aleatório para verificar e gerar solicitações de pull para atualizações de dependência.\n\nNo entanto, para reduzir a distração ou organizar melhor o tempo e os recursos para revisar e abordar atualizações de versão, você pode achar útil modificar a frequência e os intervalos. Por exemplo, você pode preferir Dependabot executar verificações semanais, em vez de diárias, para atualizações em um momento que garanta que as solicitações de pull sejam geradas antes da sessão de triagem da equipe.\n\n### Modificar a frequência e os intervalos para atualizações de dependência\n\nVocê pode usar `schedule` com uma combinação de opções para modificar a frequência e os intervalos de quando Dependabot verifica se há atualizações de versão.\n\nO arquivo de exemplo `dependabot.yml` abaixo altera a configuração do npm para especificar que Dependabot deve verificar se há atualizações de versão para dependências npm todas as terças-feiras às 02:00 Horário Padrão Japonês (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\nVeja também [agenda](/pt/code-security/dependabot/working-with-dependabot/dependabot-options-reference#schedule-).\n\n### Configurar um período de resfriamento para atualizações de dependência\n\nVocê pode usar  `cooldown` com uma combinação de opções para controlar quando Dependabot cria solicitações de pull para **atualizações de versão**, mas não **atualizações de segurança**.\n\nO arquivo de exemplo `dependabot.yml` a seguir mostra um período de resfriamento sendo aplicado às dependências `requests`, `numpy` e aqueles prefixados com `pandas` ou `django`, mas não à dependência chamada `pandas` (correspondência exata), que é excluída por meio da lista de **exclusões**.\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* O número de dias de resfriamento deve estar entre 1 e 90.\n* O limite máximo de itens permitidos nas listas`include` e `exclude`, que podem ser usados com `cooldown`, é de 150 cada.\n\n> \\[!NOTE]\n> Para considerar **todas as dependências** para um período de resfriamento, você pode:\n>\n> * Omita a opção `include` que aplica o resfriamento a todas as dependências.\n> * Use `\"*\"` na `include` para aplicar as configurações de resfriamento a tudo.\n>   Recomendamos o uso de `exclude` para excluir **apenas\\*\\*\\*\\*dependências específicas** das configurações de resfriamento.\n\nO SemVer é compatível com a maioria dos gerenciadores de pacotes. As atualizações para novas versões para dependências no resfriamento são adiadas da seguinte maneira:\n\n* Atualizações principais: atrasadas por 30 dias (`semver-major-days: 30`).\n* Atualizações secundárias: atrasadas por 7 dias (`semver-minor-days: 7`).\n* Atualizações de patch: atrasadas por 3 dias (`semver-patch-days: 3`).\n\nConsulte também [`cooldown`](/pt/code-security/dependabot/working-with-dependabot/dependabot-options-reference#cooldown-).\n\n## Como priorizar atualizações significativas\n\n### Agrupar dependências relacionadas\n\nVocê pode usar `groups` para consolidar atualizações para várias dependências em apenas uma pull request. Isso ajuda você a concentrar seu tempo de revisão em atualizações de maior risco e minimizar o tempo gasto revisando atualizações de versão secundárias. Por exemplo, você pode combinar atualizações para atualizações secundárias ou de patch para dependências de desenvolvimento em apenas uma pull request e ter um grupo dedicado para atualizações de segurança ou de versão que afetam uma área chave da base de código.\n\nVocê precisa configurar grupos por ecossistema de pacote individual e, em seguida, pode criar vários grupos por ecossistema de pacotes usando uma combinação de critérios:\n\n* Dependabot tipo de atualização: `applies-to`\n* O tipo de dependência: `dependency-type`.\n* Nome da dependência: `patterns` e `exclude-patterns`\n* Níveis de controle de versão semântico: `update-types`\n\nPara ver todos os valores com suporte para cada critério, consulte [`groups`](/pt/code-security/dependabot/working-with-dependabot/dependabot-options-reference#groups--).\n\nOs exemplos abaixo apresentam vários métodos diferentes para criar grupos de dependências usando os critérios.\n\n### Exemplo 1: três grupos de atualização de versão\n\nNeste exemplo, o arquivo `dependabot.yml`:\n\n* Cria três grupos, chamados \"`production-dependencies`\", \"`development-dependencies`\" e \"`rubocop`\".\n* Usa `patterns` e `dependency-type` para incluir dependências no grupo.\n* Usa `exclude-patterns` para excluir uma dependência (ou várias dependências) do grupo.\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\nComo resultado:\n\n* As atualizações de versão são agrupadas por tipo de dependência.\n* As dependências de desenvolvimento correspondentes ao padrão `rubocop*` são excluídas do grupo `development-dependencies`.\n* Em vez disso, as dependências de desenvolvimento correspondentes a `rubocop*` serão incluídas no grupo `rubocop`. Devido à ordenação, as dependências de produção que correspondem a `rubocop*` serão incluídas no grupo `production-dependencies`.\n* Além disso, todos os grupos são padrão para aplicar somente a atualizações de versão, já que a chave `applies-to` está ausente.\n\n### Exemplo 2: atualizações agrupadas com dependências excluídas\n\nNeste exemplo, o arquivo `dependabot.yml`:\n\n* Cria um grupo chamado \"`support-dependencies`\" como parte de uma configuração personalizada do empacotador.\n* Usa `patterns`, que correspondem ao nome de uma dependência (ou várias dependências) para incluir dependências no grupo.\n* Usa `exclude-patterns`, que correspondem ao nome de uma dependência (ou várias dependências) para excluir dependências do grupo.\n* Aplica o agrupamento apenas a atualizações de versão, já que `applies-to: version-updates` é usado.\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\nComo resultado:\n\n* A maioria das dependências do empacotador são consolidadas no grupo `support-dependencies` devido ao padrão curinga (\"\\*\"), além de\n* As dependências que correspondem `gc_ruboconfig` e `gocardless-*` são excluídas do grupo e os dados Dependabot continuam a gerar pull requests únicas para essas dependências. Isso poderá ser útil se as atualizações dessas dependências precisarem ser revisadas com mais detalhamento.\n* Para `support-dependencies`, Dependabot só gerará pull requests para atualizações de versão.\n\n### Exemplo 3: pull requests individuais para atualizações principais e agrupadas para atualizações secundárias/de patch\n\nNeste exemplo, o arquivo `dependabot.yml`:\n\n* Cria um grupo chamado \"`angular`\".\n* Usa `patterns`, que correspondem com o nome de uma dependência para incluir dependências no grupo.\n* Usa `update-type` apenas para incluir atualizações de `minor` ou `patch` no grupo.\n* Aplica o agrupamento apenas a atualizações de versão, já que `applies-to: version-updates` é usado.\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\nComo resultado:\n\n* Dependabot criará uma pull request agrupada para todas as dependências angulares que têm uma atualização secundária ou de patch.\n* Todas as atualizações principais continuarão a ser geradas como pull requests individuais.\n\n### Exemplo 4: pull requests agrupadas para atualizações secundárias/de patch e nenhuma pull request para atualizações principais\n\nNeste exemplo, o arquivo `dependabot.yml`:\n\n* Cria dois grupos chamados \"`angular`\" e \"`minor-and-patch`\".\n* Usa `applies-to` para que o primeiro grupo se aplique somente a atualizações de versão e o segundo se aplique somente a atualizações de segurança.\n* Usa `update-type` apenas para incluir atualizações `minor` ou `patch` a ambos os grupos.\n* Usa uma condição `ignore` para excluir atualizações nas versões `major` de pacotes `@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\nComo resultado:\n\n* As atualizações de versão secundária e de patch para dependências do Angular são agrupadas em apenas uma pull request.\n* Atualizações de segurança secundárias e de patch para dependências do Angular também são agrupadas em apenas uma pull request.\n* Dependabot não abrirá automaticamente pull requests para atualizações principais do Angular.\n\n### Agrupando atualizações em diretórios em um monorepo\n\nSe você gerenciar um monorepo com vários diretórios que compartilham dependências comuns, poderá reduzir o número de solicitações de pull para atualizações de versão agrupando atualizações por nome de dependência em todos os diretórios.\n\nQuando você configurar Dependabot para monitorar vários diretórios e habilitar o agrupamento por nome de dependência, Dependabot será:\n\n* Criar uma única solicitação de pull para cada atualização de dependência que afeta vários diretórios\n* Atualizar a mesma dependência para a mesma versão em todos os diretórios em uma operação\n* Reduza o número de solicitações de pull que você precisa revisar\n* Minimizar os custos de CI/CD executando testes uma vez em vez de por diretório\n\nPara obter mais informações, consulte [`group-by`](/pt/code-security/reference/supply-chain-security/dependabot-options-reference#group-by-groups).\n\nEste exemplo de configuração agrupa atualizações por nome de dependência nos diretórios `/frontend`, `/admin-panel` e `/mobile-app`. Se `lodash` precisar ser atualizado nos três diretórios, Dependabot criará uma única solicitação de pull chamada \"Bump lodash in monorepo-dependencies group\" que é atualizada `lodash` em todos os três locais.\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```"}