# Automated Pull Requests with Gradle

## Gradle

Sonatype for SCM supports updates to `build.gradle` files. During policy evaluations, Lifecycle scans your `build.gradle` files for matching components and creates a Pull Request for every match that has a remediation available.

All `build.gradle` files that exist in the repository will be examined, except `build.gradle` files in `src/test` directories, which are ignored. These are considered test files or build artifacts and not relevant project manifest files.

Only Groovy-based build files are supported. Any `gradle.properties` files found in the root directory are considered as well.

### Dependencies

Sonatype for SCM supports:

- Component defined directly inside a `dependencies` block with a literal version.

```groovy
dependencies {
    // string dependency notation
    implementation "org.apache.struts:struts2-core:2.2.1"
    // map dependency notation
    smokeTest group: 'org.springframework', name: 'spring-api', version: '2.5'
}
```

- Component defined inside a `constraints` block of a `dependencies` block with a literal version.

```groovy
dependencies {
    constraints {
      // string dependency notation
      implementation "org.apache.struts:struts2-core:2.2.1"
      // map dependency notation
      smokeTest group: 'org.springframework', name: 'spring-api', version: '2.5'
    }
}
```

- Component defined inside a `dependencies` block with a property or variable version. Component versions are also looked up in the `gradle.properties` file, if one exists.

```groovy
// Project property
ext {
    slf4jSimpleVersion = '1.7.30'
}

// Groovy variable - dynamic typed
def jerseyVersion = '2.29.1'

// Groovy variable - static typed
String jerseyVersionStr = '2.29.1'

dependencies {
    implementation group: 'org.glassfish.jersey.core', name: 'jersey-core', version: jerseyVersion
    implementation group: 'org.glassfish.jersey.core', name: 'jersey-common', version: jerseyVersionStr
    implementation "org.slf4j:slf4j-simple:$slf4jSimpleVersion"
}
```

- Component defined inside a `dependencies` block with version constraints.

```groovy
// project-level inline declaration
ext.slf4jVersion = '1.7.30'

dependencies {
    implementation('org.slf4j:slf4j-api') {
      version {
        strictly '[1.7, 1.8['\
        prefer "$slf4jVersion"\
      }\
    }\
}\
```

- Gradle version ranges are supported for all the above-mentioned cases.

```groovy
ext {
    asmVersion = '[7.1,['
}

dependencies {
    implementation "org.apache.struts:struts2-core:[2.2.1 , 2.2.10)"
    implementation group: 'org.slf4j', name: 'slf4j-core', version: ']1.20,1.30['
    implementation('org.ow2.asm:asm')
    constraints {
      implementation("org.ow2.asm:asm:$asmVersion") {
        because 'we require a JDK 9 compatible bytecode generator'
      }
    }
    implementation('org.slf4j:slf4j-simple') {
      version {
        require '[1.7, 1.8['
        prefer '1.7.25'
        reject '1.7.20', '1.7.21'
      }
    }
}
```

### Version Pinning and Best Practices

Sonatype for SCM will always bump to a specific version by pinning it in the manifest.

In the below range syntax example, this means that a `build.gradle` containing:

```groovy
dependencies {
  implementation "org.apache.struts:struts2-core:[2.2.1 , 2.2.10)"
}
```

This will result in a pull request to replace the contents with (assuming that version 2.2.8 passes the policy check):

```groovy
dependencies {
  implementation "org.apache.struts:struts2-core:2.2.8"
}
```

**Important:** Pinning your dependency version is a best practice. Only a pinned version allows you to control remediation through security and quality policies. For the above example, version 2.2.8 might pass a policy check, but version 2.2.9 might not. A version range does not allow this type of control.

## Search results

No results found