{"meta":{"title":"Customizing Dependabot pull requests to fit your processes","intro":"Learn how to tailor your Dependabot pull requests to better suit your own internal workflows.","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/customizing-dependabot-prs","title":"Customize Dependabot PRs"}],"documentType":"article"},"body":"# Customizing Dependabot pull requests to fit your processes\n\nLearn how to tailor your Dependabot pull requests to better suit your own internal workflows.\n\nThere are various ways to customize your Dependabot pull requests so that they better suit your own internal processes.\n\nFor example, to integrate Dependabot's pull requests into your CI/CD pipelines, it can apply **custom labels** to pull requests, which you can then use to trigger action workflows.\n\nThere are several different customization options which can all be used in combination, and tailored per package ecosystem.\n\n## Automatically adding assignees\n\nBy default, Dependabot raises pull requests without any assignees.\n\nTo automatically assign pull requests to a designated security team, you can use `assignees` to set these values per package ecosystem.\n\nThe example `dependabot.yml` file below changes the npm configuration so that all pull requests opened with version and security updates for npm have:\n\n* An individual (\"`user-name`\") automatically assigned to the pull requests.\n\n```yaml copy\n# `dependabot.yml` file with\n#  assignee for all npm pull requests\n\nversion: 2\nupdates:\n  # Keep npm dependencies up to date\n  - package-ecosystem: \"npm\"\n    directory: \"/\"\n    schedule:\n      interval: \"weekly\"\n    # Raise all npm pull requests with assignees\n    assignees:\n      - \"user-name\"\n```\n\n## Automatically adding reviewers\n\nBy default, Dependabot raises pull requests without any reviewers.\n\nTo ensure your project's security updates get addressed promptly by the appropriate team, you can automatically add reviewers to Dependabot pull requests using a CODEOWNERS file. See [About code owners](/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).\n\n## Labeling pull requests with custom labels\n\nBy default, Dependabot raises pull requests with the `dependencies` label.\n\nDependabot also applies an ecosystem label, such as `java`, `npm`, or `github-actions`, to pull requests. Dependabot adds both the `dependencies` label and the ecosystem label to all pull requests, including single-ecosystem updates, to improve filtering and triaging.\n\nDependabot creates the default labels it applies to pull requests if they do not already exist in the repository. If you want to use custom labels instead of the defaults, you can set the `labels` option in your `dependabot.yml` file per package ecosystem; this overrides the defaults. For more information, see [Managing labels](/en/issues/using-labels-and-milestones-to-track-work/managing-labels) and [`labels`](/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference#labels--).\n\nIf semantic version (SemVer) labels are present in the repository, Dependabot will also automatically apply them to indicate the type of version update (`major`, `minor`, or `patch`). These labels are applied in addition to any custom labels you define.\n\nYou can use `labels` to override the default labels and specify your own custom labels per package ecosystem. This is useful if, for example, you want to:\n\n* Use labels to assign a priority to certain pull requests.\n* Use labels to trigger another workflow, such as automatically adding the pull request onto a project board.\n\nThe example `dependabot.yml` file below changes the npm configuration so that all pull requests opened with version and security updates for npm have custom labels.\n\n```yaml copy\n# `dependabot.yml` file with\n# customized npm configuration\n\nversion: 2\nupdates:\n  # Keep npm dependencies up to date\n  - package-ecosystem: \"npm\"\n    directory: \"/\"\n    schedule:\n      interval: \"weekly\"\n    # Raise all npm pull requests with custom labels\n    labels:\n      - \"npm dependencies\"\n      - \"triage-board\"\n```\n\nSetting this option will also affect pull requests for security updates to the manifest files of this package manager, unless you use `target-branch` to check for version updates on a non-default branch.\n\nSee also [`labels`](/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference#labels--).\n\n## Adding a prefix to commit messages\n\nBy default, Dependabot attempts to detect your commit message preferences and use similar patterns. In addition, Dependabot populates the titles of pull requests based on the commit messages.\n\nYou can specify your own prefix for Dependabot's commit messages (and pull request titles) for a specific package ecosystem. This can be useful if, for example, you're running automations that process commit messages or pull requests titles.\n\nTo specify your preferences explicitly, use `commit-message` together with the following supported options:\n\n* `prefix`:\n  * Specifies a prefix for all commit messages.\n  * Prefix is also added to the start of the pull request title.\n* `prefix-development`:\n  * Specifies a separate prefix for all commit messages that update development dependencies, as defined by the package manager or ecosystem.\n  * Supported for `bundler`, `composer`, `mix`, `maven`, `npm`, and `pip`.\n* `include: \"scope\"`:\n  * Specifies that any prefix is followed by the dependency types (`deps` or `deps-dev`) updated in the commit.\n\nThe example below shows several different options, tailored per package ecosystem:\n\n```yaml copy\n# Customize commit messages\n\nversion: 2\nupdates:\n  - package-ecosystem: \"npm\"\n    directory: \"/\"\n    schedule:\n      interval: \"weekly\"\n    commit-message:\n      # Prefix all commit messages with \"npm: \"\n      prefix: \"npm\"\n\n  - package-ecosystem: \"docker\"\n    directory: \"/\"\n    schedule:\n      interval: \"weekly\"\n    commit-message:\n      # Prefix all commit messages with \"[docker] \" (no colon, but a trailing whitespace)\n      prefix: \"[docker] \"\n\n  - package-ecosystem: \"composer\"\n    directory: \"/\"\n    schedule:\n      interval: \"weekly\"\n    # Prefix all commit messages with \"Composer\" plus its scope, that is, a\n    # list of updated dependencies\n    commit-message:\n      prefix: \"Composer\"\n      include: \"scope\"\n\n  - package-ecosystem: \"pip\"\n    directory: \"/\"\n    schedule:\n      interval: \"weekly\"\n    # Include a list of updated dependencies\n    # with a prefix determined by the dependency group\n    commit-message:\n      prefix: \"pip prod\"\n      prefix-development: \"pip dev\"\n```\n\nSetting this option will also affect pull requests for security updates to the manifest files of this package manager, unless you use `target-branch` to check for version updates on a non-default branch.\n\nSee also [`commit-message`](/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference#commit-message--).\n\n## Associating pull requests with a milestone\n\nMilestones help you track the progress of groups of pull requests (or issues) towards a project goal or release. With Dependabot, you can use the `milestone` option to associate pull requests for dependency updates with a specific milestone.\n\nYou must specify the numeric identifier of the milestone and not its label. To find the numeric identifier, check the final part of the page URL, after `milestone`. For example, for `https://github.com/<org>/<repo>/milestone/3`, \"`3`\" is the numeric identifier of the milestone.\n\n```yaml copy\n# Specify a milestone for pull requests\n\nversion: 2\nupdates:\n  - package-ecosystem: \"npm\"\n    directory: \"/\"\n    schedule:\n      interval: \"weekly\"\n    # Associate pull requests with milestone \"4\"\n    milestone: 4\n```\n\nSetting this option will also affect pull requests for security updates to the manifest files of this package manager, unless you use `target-branch` to check for version updates on a non-default branch.\n\nSee also [`milestone`](/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference#milestone--) and [About milestones](/en/issues/using-labels-and-milestones-to-track-work/about-milestones).\n\n## Changing the separator in the pull request branch name\n\nDependabot generates a branch for each pull request. Each branch name includes `dependabot`, as well as the name of the package manager and the dependency to be updated. By default, these parts of the branch name are separated by a `/` symbol, for example:\n\n* `dependabot/npm_and_yarn/next_js/acorn-6.4.1`\n\nTo maintain supportability or consistency with your existing processes, you may need to ensure your branch names align with your team's existing conventions. In this case, you can use `pull-request-branch-name.separator` to specify a different separator, choosing either `_`, `/`, or `\"-\"`.\n\nIn the below example, the npm configuration changes the default separator from `/` to `\"-\"`, so that it would appear as such:\n\n* Default (`/`): `dependabot/npm_and_yarn/next_js/acorn-6.4.1`\n* Customized (`\"-\"`): `dependabot-npm_and_yarn-next_js-acorn-6.4.1`\n\nNote that the hyphen symbol (`\"-\"`) must be surrounded by quotation marks so that it's not interpreted as starting an empty YAML list.\n\n```yaml copy\n# Specify a different separator for branch names\n\nversion: 2\nupdates:\n  - package-ecosystem: \"npm\"\n    directory: \"/\"\n    schedule:\n      interval: \"weekly\"\n    pull-request-branch-name:\n      # Change the default separator (/) to a hyphen (-)\n      separator: \"-\"\n```\n\nSetting this option will also affect pull requests for security updates to the manifest files of this package manager, unless you use `target-branch` to check for version updates on a non-default branch.\n\nSee also [`pull-request-branch-name.separator`](/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference#pull-request-branch-nameseparator--).\n\n## Targeting pull requests against a non-default branch\n\nBy default, Dependabot checks for manifest files on the default branch and raises pull requests for updates against the default branch.\n\nGenerally, it makes most sense to keep Dependabot's checks and updates on the default branch. However, there may be some cases where you may need to specify a different target branch. If, for example, your team's processes require you to first test and validate updates on a non-production branch, you can use `target-branch` to specify a different branch for Dependabot to raise pull requests against.\n\n> \\[!NOTE]\n> Dependabot raises pull requests for security updates against the **default branch only**. If you use `target-branch`, then as a result, all configuration settings for that package manager will then *only* apply to version updates, and not security updates.\n\n```yaml copy\n# Specify a non-default branch for pull requests for pip\n\nversion: 2\nupdates:\n  - package-ecosystem: \"pip\"\n    directory: \"/\"\n    schedule:\n      interval: \"weekly\"\n    # Raise pull requests for version updates\n    # to pip against the `develop` branch\n    target-branch: \"develop\"\n    # Labels on pull requests for version updates only\n    labels:\n      - \"pip dependencies\"\n\n  - package-ecosystem: \"npm\"\n    directory: \"/\"\n    schedule:\n      interval: \"weekly\"\n      # Check for npm updates on Sundays\n      day: \"sunday\"\n    # Labels on pull requests for security and version updates\n    labels:\n      - \"npm dependencies\"\n```\n\nSee also [`target-branch`](/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference#target-branch-)."}