{"meta":{"title":"Optimizing the creation of pull requests for Dependabot version updates","intro":"Learn how to streamline and efficiently manage your Dependabot pull requests.","product":"Security and code quality","breadcrumbs":[{"href":"/en/code-security","title":"Security and code quality"},{"href":"/en/code-security/tutorials","title":"Tutorials"},{"href":"/en/code-security/tutorials/secure-your-dependencies","title":"Secure your dependencies"},{"href":"/en/code-security/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates","title":"Optimize PR creation"}],"documentType":"article"},"body":"# Optimizing the creation of pull requests for Dependabot version updates\n\nLearn how to streamline and efficiently manage your Dependabot pull requests.\n\nBy default, Dependabot opens a new pull request to update each dependency. When you enable security updates, new pull requests are opened when a vulnerable dependency is found. When you configure version updates for one or more ecosystems, new pull requests are opened when new versions of dependencies are available, with the frequency defined in the `dependabot.yml` file.\n\nIf your project has many dependencies, you might find that you have a very large number of Dependabot pull requests to review and merge, which can quickly become difficult to manage.\n\nThere are a couple of customization options you can implement to optimize Dependabot update pull requests to align with your processes, such as:\n\n* **Controlling the frequency** with which Dependabot checks for newer versions of your dependencies with `schedule`.\n* **Prioritize meaningful updates** with `groups`.\n\n## Controlling the frequency and timings of dependency updates\n\nDependabot runs its checks for version updates at a frequency set by you in the configuration file, where the required field, `schedule.interval`, must be set to `daily`, `weekly`, `monthly`, `quarterly`, `semiannually`, `yearly`, or `cron` (see [`cronjob`](/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference#cronjob)).\n\nBy default, Dependabot balances its workload by assigning a random time to check and raise pull requests for dependency updates.\n\nHowever, to reduce distraction, or to better organize time and resources for reviewing and addressing version updates, you might find it useful to modify the frequency and timings. For example, you may prefer Dependabot to run weekly rather than daily checks for updates, and at a time that ensures pull requests are raised before for your team's triage session.\n\n### Modifying the frequency and timings for dependency updates\n\nYou can use `schedule` with a combination of options to modify the frequency and timings of when Dependabot checks for version updates.\n\nThe example `dependabot.yml` file below changes the npm configuration to specify that Dependabot should check for version updates to npm dependencies every Tuesday at 02:00 Japanese Standard Time (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\nSee also [schedule](/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference#schedule-).\n\n### Setting up a cooldown period for dependency updates\n\nYou can use  `cooldown` with a combination of options to control when Dependabot creates pull requests for **version updates**, but not **security updates**.\n\nThe example `dependabot.yml` file below shows a cooldown period being applied to the dependencies `requests`, `numpy`, and those prefixed with `pandas` or `django`, but not to the dependency called `pandas` (exact match), which is excluded via the **exclude** list.\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* The number of cooldown days must be between 1 and 90.\n* The maximum allowed items limit in `include` and `exclude` lists, which can be used with `cooldown`, is 150 each.\n\n> \\[!NOTE]\n> To consider **all dependencies** for a cooldown period, you can:\n>\n> * Omit the `include` option which applies cooldown to all dependencies.\n> * Use `\"*\"` in `include` to apply the cooldown settings to everything.\n>   We recommend the use of `exclude` to **only** exclude **specific dependencies** from cooldown settings.\n\nSemVer is supported for most package managers. Updates to new versions for dependencies in cooldown are deferred as follows:\n\n* Major updates: Delayed by 30 days (`semver-major-days: 30`).\n* Minor updates: Delayed by 7 days (`semver-minor-days: 7`).\n* Patch updates: Delayed by 3 days (`semver-patch-days: 3`).\n\nSee also [`cooldown`](/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference#cooldown-).\n\n## Prioritizing meaningful updates\n\n### Grouping related dependencies together\n\nYou can use `groups` to consolidate updates for multiple dependencies into a single pull request. This helps you focus your review time on higher risk updates, and minimize the time spent reviewing minor version updates. For example, you can combine updates for minor or patch updates for development dependencies into a single pull request, and have a dedicated group for security or version updates that impact a key area of your codebase.\n\nYou must configure groups per individual package ecosystem, then you can create multiple groups per package ecosystem using a combination of criteria:\n\n* Dependabot update type: `applies-to`\n* Type of dependency: `dependency-type`.\n* Dependency name: `patterns` and `exclude-patterns`\n* Semantic versioning levels: `update-types`\n\nTo see all supported values for each criterion, see [`groups`](/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference#groups--).\n\nThe below examples present several different methods to create groups of dependencies using the criteria.\n\n### Example 1: Three version update groups\n\nIn this example, the `dependabot.yml` file:\n\n* Creates three groups, called \"`production-dependencies`\", \"`development-dependencies`\", and \"`rubocop`\".\n* Uses `patterns` and `dependency-type` to include dependencies in the group.\n* Uses `exclude-patterns` to exclude a dependency (or multiple dependencies) from the group.\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\nAs a result:\n\n* Version updates are grouped by dependency type.\n* Development dependencies matching the pattern `rubocop*` are excluded from the `development-dependencies` group.\n* Instead, development dependencies matching `rubocop*` will be included in the `rubocop` group. Due to the ordering, production dependencies matching `rubocop*` will be included in the `production-dependencies` group.\n* In addition, all groups default to applying to version updates only, since the `applies-to` key is absent.\n\n### Example 2: Grouped updates with excluded dependencies\n\nIn this example, the `dependabot.yml` file:\n\n* Creates a group called \"`support-dependencies`,\" as part of a customized Bundler configuration.\n* Uses `patterns` that match with the name of a dependency (or multiple dependencies) to include dependencies in the group.\n* Uses `exclude-patterns` that match with the name of a dependency (or multiple dependencies) to exclude dependencies from the group.\n* Applies the grouping to version updates only, since `applies-to: version-updates` is used.\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\nAs a result:\n\n* The majority of dependencies for bundler are consolidated into the `support-dependencies` group due to the wildcard (\"\\*\") pattern, apart from\n* Dependencies that match `gc_ruboconfig` and `gocardless-*` are excluded from the group, and Dependabot continues to raise single pull requests for these dependencies. This can be helpful if updates for these dependencies need to be reviewed with closer scrutiny.\n* For `support-dependencies`, Dependabot will only raise pull requests for version updates.\n\n### Example 3: Individual pull requests for major updates and grouped for minor/patch updates\n\nIn this example, the `dependabot.yml` file:\n\n* Creates a group called \"`angular`.\"\n* Uses `patterns` that match with the name of a dependency to include dependencies in the group.\n* Uses `update-type` to only include `minor` or `patch` updates in the group.\n* Applies the grouping to version updates only, since `applies-to: version-updates` is used.\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\nAs a result:\n\n* Dependabot will create a grouped pull request for all Angular dependencies that have a minor or patch update.\n* All major updates will continue to be raised as individual pull requests.\n\n### Example 4: Grouped pull requests for minor/patch updates and no pull requests for major updates\n\nIn this example, the `dependabot.yml` file:\n\n* Creates two groups called \"`angular`\" and \"`minor-and-patch`\".\n* Uses `applies-to` so that the first group applies to version updates only, and the second group applies to security updates only.\n* Uses `update-type` to only include `minor` or `patch` updates for both groups.\n* Uses an `ignore` condition to exclude updates to `major` versions of `@angular*` packages.\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\nAs a result:\n\n* Minor and patch version updates for Angular dependencies are grouped into a single pull request.\n* Minor and patch security updates for Angular dependencies are also grouped together into a single pull request.\n* Dependabot won't automatically open pull requests for major updates for Angular.\n\n### Grouping updates across directories in a monorepo\n\nIf you manage a monorepo with multiple directories that share common dependencies, you can reduce the number of pull requests for version updates by grouping updates by dependency name across all directories.\n\nWhen you configure Dependabot to monitor multiple directories and enable grouping by dependency name, Dependabot will:\n\n* Create a single pull request for each dependency update that affects multiple directories\n* Update the same dependency to the same version across all directories in one operation\n* Reduce the number of pull requests you need to review\n* Minimize CI/CD costs by running tests once instead of per directory\n\nFor more information, see [`group-by`](/en/code-security/reference/supply-chain-security/dependabot-options-reference#group-by-groups).\n\nThis configuration example groups updates by dependency name across the `/frontend`, `/admin-panel`, and `/mobile-app` directories. If `lodash` needs to be updated in all three directories, Dependabot will create a single pull request named \"Bump lodash in monorepo-dependencies group\" that updates `lodash` in all three locations.\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```"}