Automated Pull Requests



Sonatype IQ for SCM will automatically create pull requests for policy violations on components that have an available version which remediates those violations.

After any policy evaluation that generates new violations with available remediations, the IQ Server will clone the repository and attempt to create a pull request to bump the component to the new version. The pull request will contain links to the full IQ policy report that triggered it as well as direct links to any security vulnerability details.

Currently supported platforms: GitHub

Currently supported ecosystems: Maven


Private repositories

Automated pull requests will only work on repositories that cannot be accessed publicly. On this means that the repository will need to be private. On GitHub Enterprise all repositories will work.

Minimum Git Client Version

If the native git client is installed and available on the path it is preferred. The minimum git version that has been tested is version 2.16.0.

Token permissions

Automated pull requests require the repo scope. See the GitHub documentation for details on this scope:

See the 'Access Token' section under Source Control Configuration.


To enable pull requests, ensure that your application is configured with:

  • a repository URL
  • a token for your SCM system (see Token Permissions in Requirements)
  • the 'Pull Requests' option is enabled
  • a default branch to use as the 'base branch' for the pull request

The repository URL must be at the application level, but the other attributes can be at the application, organization, or root organization level. See Source Control Configuration for more details.

Repository URL

The repository URL must be entered as an https  URL. For example The trailing .git is optional. Entering a git:// style URL is not supported. The same repository URL may be used for multiple IQ applications.

Default branch

This option lets you configure which git branch should be the base branch for pull requests created for this IQ application. The default value is the master  branch.

Common usage scenarios:

  1. All development happens off a primary single branch (normally master). This is the most common approach you would see on most OSS components on Github. Pull requests are created off of master and merged right in. Here you would just use the default value of master for the default branch.
  2. The master branch is reserved for production and kept in a deployable state. Commonly known as Git Flow, development occurs on another branch (e.g. develop) and pull requests are created off this branch. Once the development branch is ready for release it is merged to master. Here you would use the value of the development branch (e.g. develop) for the default branch.
  3. Some git repositories have multiple stable branches (for example jgit). Here each branch would be a separate IQ application and each would be configured for the appropriate branch.

IQ Configuration file (config.yml) Options

These configuration options can be set in the Nexus IQ Server configuration file. See the main documentation for the config.yml for details on how to modify this file.

Location on disk of cloned repositories

For each configured application, the repository will be cloned on the host the IQ Server runs on. The default location is:


Note that the default for sonatypeWork  is ./sonatype-work/clm-server

This can be customized in the config.yml with:

  cloneDirectory: /your/path/here

If a leading "/" is not specified, then the path will be relative to <sonatypeWork>.

Git Client

Automated pull requests will work out of the box with no additional software installations necessary using the bundled JGit application library. JGit is a Java implementation of git that supports all git functionality necessary for the pull requests feature. However, JGit does not support two git features that can improve performance: shallow clone and sparse checkout. Shallow clones allow us to only clone the minimal amount of git history to enable the feature, and sparse checkouts allow us to only checkout the files necessary to bumping versions. These two features provide large disk-space savings, increased time performance and reduced network traffic.

If the native git client is installed and available on the system path, then it will be preferred over JGit. If you are having problems with native git, this behaviour can be overridden in the config.yml by forcing the usage of java git (JGit).

  gitImplementation: java

Git Executable

If a native git client is installed but is not on the system path, the fully qualified path to the executable can be specified.

  gitExecutable: /usr/bin/git

Version Bumping

When the feature checks out your source and attempts to find the component to remediate, it must be able to be found within the manifest.


  • Component defined inside a <dependencies> element with an inline <version> element.

  • Component defined inside a <dependencyManagement> element with an inline <version> element.

  • Component defined inside either a <dependencies> element, or a <dependencyManagement> element, with the version defined via a variable in a <properties> section.


If the component and version cannot be found in the repository source, a pull request cannot be created.