question for people using dependency locking: sinc...
# dependency-management
question for people using dependency locking: since it leads to a build failure if there are any changes in the resolved dependencies of a build, what kind of pushback have you had from non-build engineers? Are they frustrated by this additional friction? how have you minimized that, assuming you've tried to do so? any lessons learned?
not using dependency locking on any current projects, but created and maintained something equivalent previously (before Gradle's native dependency locking). other engineers were not happy but pushback was obviated by "our legal department interprets PCI compliance to require this"
šŸ˜‚ 1
That's why I created dependency guard. Need to share publicly, but happy to do a private demo.
@Sam Edwards interesting. I wonder what would make your situation different from mine? Because I tried changing a dependency and got a build failure when running `:dependencies`:
Copy code
* What went wrong:
A problem occurred configuring root project 'register'.
> Could not resolve all files for configuration ':classpath'.
   > Resolved '' which is not part of the dependency lock state
this was for the build classpath
In mine, you can change any dependencies you want. But if you run
./gradlew dependencyGuard
then it'll compare to the baseline and fail with the difference. Then you can rebase with
./gradlew dependencyGuardBaseline
. You can do a dependsOn() if you want to commonly run the
task to find the change early, but otherwise you can have CI fail the build with it. It just forces "intentional dependency changes". The big part of it is catching transitive dependencies for a specific config.
I have 3 baseline artifacts. 1. artifacts (3rd party) Enabled by default 2. local project modules (disabled by default) 3. tree format (dependencies --configuration blah). It can compare all 3. The first one is the most useful, but all can be in certain situations.
I tried dependency locking when it created many files, it was terrible. Once it's just one file a team tried (and I think they are using it) but the last thing I know is that it was frustrating all the time because if failed when it shouldn't... Mostly it seems an issue of having too many configurations (Android project + typical static analysis tools). The only reason they wanted to use it is to detect transitive dependencies changing. With dependency locking they can see the change in the PR.
I'm wondering if what I want is dependency verification. But really, neither appears to be quite intended for my use-case, which is simply to see when a version changes or when a new (usually transitive) dependency appears. They both can do that, but that does not seem to be the intended purpose. Dependency verification is probably worth doing anyway, for security reasons, but...
I think your usecase is the same I was speaking of. "I want to notice changes in transitive dependencies so my app doesn't unexpectedly in runtime later"
(I think it was some jetpack lib that changed for us a couple of times, compiling fine but exploding in runtime)
The "good" of dependency locking in that case is that the PR author sees the change when he has to update the lib, but also is in the PR changelog so everyone can see it.
The bad many configurations your project has? Are you blocking them all?
And I don't have access to the chat anymore, but I think I'm remembering they had an issue with a dependency that is resolved in task execution so it wasn't written.
If your need is only to detect transitive dependency changes in PRs, then have a look at
It's not good you have the same problem as me, but you do!
This is exactly what dependency guard does. I have 3 formats I support: ā€¢ artifacts ā€¢ local modules/projects ā€¢ tree (using JW's logic) Will show you the diff of all the transitives and allow you to re-baseline. Also, error messaging is šŸ’Æ , so it's clear to see wh at's up.
Let me see if I can open source it this week...
Working on it šŸ¤ž
šŸŽ‰ 2
Nice, I pushed up the code to the private Github repo. Awaiting legal approval, then would just have to setup stuff like CI/CD for it and can share after all that. Hopefully be end of week šŸ¤ž
I was able to flip the switch on it: It's still a work in progress before I publish a non-snapshot, but it is working, so any feedback is appreciated. A
is available. Thanks @tony for using the Github issue track for the feedback you have given so far!
šŸŽ‰ 2