Use a task for dependency locking

Help/Discuss
1

I am wondering if it is possible to use a gradle task for dependency locking rather than relying on the --write-locks command line parameter?

What I come up with at the moment is to run another command line command inside a task:

task lockDependencies {
    './gradlew dependencies --write-locks'.execute()

    'git add /gradle/dependency-locks'.execute()
}

I will then make my release task depend on lockDependencies so that dependency lock is generated and committed automatically when release task runs.

The approach does feel a bit weird though. Please let me know if there is a more straightforward way.

Thanks

2 Likes
2

I’d also really like this. I want to create a nightly job on CircleCI that updates locks, runs tests and commits the result if successful.

3

The documentation shows an task which can be used (instead of the dependencies task).

But adding it to a VCS (and commiting it) is a whole new thing and can be archived like you did.
From my point of view there is nothing wrong using git add /gradle/dependency-locks'.execute().

4

Thanks. But I think the task in the documentation is not really doing the locking part. It is just a custom task which will result in all dependencies being resolved. The actual locking is still going to be trigger by --write-locks. If you look at the assertion in the doFirst:

assert gradle.startParameter.writeDependencyLocks

If I understand it correctly, it asserts that the task must be invoked in the form of

gradle resolveAndLockAll --write-lock
6

Hey there,

Sorry I totally missed that post when it appeared.

The reason behind making dependency locking work with command line flags was to ensure Gradle would know about it, including for build script classpath configuration resolution.
Using a task for such early resolution in the lifecycle of a build is not practical.

Also a task is really about performing work in your build, while with locking, the generation or update of lock files is really a side effect of what’s running in the build.

I am interested in understanding how the reliance on a switch instead of a task names complicates the CI scenario described above or other ones.