Hi!
I would like to confirm with the experts here. I’m a security engineer and I would like our teams to use dependency locking since it generates lockfiles that will be easier to pick up by dependency scanners like Snyk. Unfortunately, forcing such changes on the teams is hard and I would like to keep it minimal impact for now. Looking through the docs, does adding this to the gradle file suffice?
dependencyLocking {
lockMode = LockMode.LENIENT
}
My goal is to generate the locks, but not fail if they are not being adhered to.
Are there better approaches to this from your perspective?
The conventional way to share build logic across projects is to create a Gradle plugin which projects then apply in their builds script. For example,
plugins {
... // Any other plugins a team is using
id("org.mycompany.dependency-security").version("1.0")
}
When you’ve created your Gradle plugin, which applies your desired build configurations, you can publish it to your internal package repository. If you do it like this, then you avoid duplicating build logic across all builds. If one day requirements change in security engineering, such that all builds need to update, you can just publish a new version of your plugin. Asking teams to update their plugin version number is a lot easier and less error prone than asking them to again to copy-paste some configuration into their build scripts.
For dependency locking, your configuration looks correct to me, but I’m not an expert with that. One way that you might gain more confidence in your solution would be by writing an automated test using TestKit.
Thanks for the new direction here, I like the idea! I’ll check it out and hopefully be able to make use of it. I’m a bit worried that writing such a plugin is a more involved task and could have side-effects (e.g. what happens with teams that already have the dependency locking enabled, which setting is prioritized?).
