-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Start updating Gradle lockfiles #12287
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Start updating Gradle lockfiles #12287
Conversation
gradle/spec/fixtures/buildfiles/lockfile/app/src/main/java/org/example/App.java
Outdated
Show resolved
Hide resolved
0e856d0
to
cfd4a1f
Compare
aed48b3
to
89bbc02
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR adds support for updating Gradle lockfiles when bumping dependencies, including fixtures, a new LockfileUpdater
, tests, and Docker/DevContainer updates to enable lockfile generation.
- Introduces complete Gradle project fixtures with lockfiles and wrapper scripts for testing
- Implements
LockfileUpdater
and integrates it intoFileUpdater
, with Sorbet type signatures and new tests - Updates the Docker image to install Java and Gradle and pins Rust in the DevContainer
Reviewed Changes
Copilot reviewed 19 out of 19 changed files in this pull request and generated 1 comment.
Show a summary per file
File | Description |
---|---|
gradle/spec/fixtures/buildfiles/lockfile/** | Adds a full sample Gradle project with lockfiles |
gradle/spec/dependabot/gradle/file_updater_spec.rb | Adds specs for lockfile-aware dependency updates |
gradle/lib/dependabot/gradle/file_updater/property_value_updater.rb | Adds Sorbet signatures and null-safety improvements |
gradle/lib/dependabot/gradle/file_updater/lockfile_updater.rb | Implements lockfile regeneration via gradle build --write-locks |
gradle/lib/dependabot/gradle/file_updater.rb | Integrates the lockfile updater into the main updater |
gradle/Dockerfile | Installs OpenJDK and Gradle for lockfile generation |
.devcontainer/devcontainer.json | Pins Rust version to 1.86.0 for the dev environment |
Comments suppressed due to low confidence (2)
gradle/Dockerfile:28
- The Dockerfile invokes
unzip gradle.zip
but theunzip
package is not installed. Addunzip
to the apt-get install list to ensure the command succeeds.
&& unzip gradle.zip \
gradle/lib/dependabot/gradle/file_updater/property_value_updater.rb:45
- [nitpick] Using
T.must
onfile_to_update.content
is redundant sincecontent
is always a non-nil String; consider removingT.must
for clarity.
updated_content = T.must(file_to_update.content).sub(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey,
Gradle engineer here, having implemented lock files for it.
I am a strong +1 in adding support for upgrading lockfiles for Dependabot when they are present. @ryanbrandenburg has the right justification.
While I can't really comment on the details of the code - ruby is not my specialty - I left one main comment, on the update approach itself.
gradle/spec/fixtures/buildfiles/lockfile/app/src/main/java/org/example/App.java
Outdated
Show resolved
Hide resolved
…into dev/rybrande/GradleCLI
@kbukum1 looks like you might be the representative for |
@ryanbrandenburg, yes, I am currently reviewing this. I will let you know when I am done. Thanks for the contribution. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Testing the changes
Hi @ryanbrandenburg , Thanks for adding feature flag. I am currently testing it. I will let you know if there is any issue. I also created feature flag on our api side so we can use it for rollout. Locally seems like it is doing properly. After a few more tests I will test it on a direct repository.
|
Local test is done and working properly in dry-run mode.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nicely done! @ryanbrandenburg — thank you for considering all perspectives and keeping the change behind a feature flag. Also, appreciate you adding the Sorbet typings!
What are you trying to accomplish?
Many Gralde Repositories check their gradle.lockfile's into the repository for build reproducibility, so if they get a Dependabot PR which updates their gradle.build files without updating the gradle.lockfile's it's liable to cause build failures which they will have to resolve by updating the lockfiles themselves. By running
gradle build
when the repo has checked in lockfiles we can hopefully avoid that scenerio, and if for whatever reason it doesn't work than people are back to being able to update the lockfile themselves.#2222
Anything you want to highlight for special attention from reviewers?
How will you know you've accomplished your goal?
We'll know this works if we can run a successful package upgrade against a repo which uses a lockfile and the lockfile updates.
Checklist