dependabot / dependabot/dependabot-core
Add support for Gradle's Dependency Verification feature
- Dominant language
- Ruby
- Stars
- 5.8k
- Forks
- 1.5k
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 149
Description
I'm using gradle to build my Java project https://github.com/marco-schmidt/am Dependabot is enabled for this project and regularly creates pull requests for new dependency versions.
I recently started using gradle's new dependency verification feature: https://docs.gradle.org/current/userguide/dependency_verification.html
In a nutshell, that feature will test all files belonging to dependencies (libraries, plug-ins) against a list of allowed hash values to make sure repositories cannot introduce malware with slightly modified versions of popular dependencies: https://github.com/marco-schmidt/am/blob/master/gradle/verification-metadata.xml
Naturally, whenever a new version of a dependency is being used, its hash value is not yet contained in that XML file. Therefore, dependabot updating a version number now always results in a failed attempt to build, making it less useful and interfering with the statistics for successful upgrades (the compatibility percentage value shown in the pull request).
In order to keep the verification feature happy, a parameter can be used to update the XML file:
`./gradlew build --write-verification-metadata sha256`
How can I make Dependabot use that additional argument? I don't want to use that argument all the time because I want the build to fail on developer machines (including mine) if unknown or modified file versions appear.
Or is there any other way to handle this situation?
Thanks for providing Dependabot,
Marco
Contributor guide
Research direction
Start by examining how Gradle build invocations are handled and how the project's gradle/verification-metadata.xml is updated. Compare the normal ./gradlew build command with ./gradlew build --write-verification-metadata sha256. Done means dependency update pull requests keep verification metadata current without weakening verification for developer builds.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- build-system, devtools
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100