# Use a task for dependency locking

**URL:** <https://discuss.gradle.org/t/use-a-task-for-dependency-locking/28657>\
**Category:** Help/Discuss\
**Created:** [September 18, 2018, 9:00am UTC](https://discuss.gradle.org/t/use-a-task-for-dependency-locking/28657 "2018-09-18T09:00:53Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Xinchao](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/xinchao/32/6490_2.png) [@Xinchao](https://discuss.gradle.org/u/Xinchao)\
**Post date:** [September 18, 2018, 9:00am UTC](https://discuss.gradle.org/t/use-a-task-for-dependency-locking/28657/1 "2018-09-18T09:00:53Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![robfletcher](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/robfletcher/32/7211_2.png) [@robfletcher](https://discuss.gradle.org/u/robfletcher)\
**Post date:** [September 21, 2018, 8:24pm UTC](https://discuss.gradle.org/t/use-a-task-for-dependency-locking/28657/2 "2018-09-21T20:24:19Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![StefMa](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/stefma/32/9384_2.png) [@StefMa](https://discuss.gradle.org/u/StefMa)\
**Post date:** [September 24, 2018, 7:12am UTC](https://discuss.gradle.org/t/use-a-task-for-dependency-locking/28657/3 "2018-09-24T07:12:37Z")

</div>

[The documentation](https://docs.gradle.org/4.10.2/userguide/dependency_locking.html#example_resolving_all_configurations) 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()`.

---

<div class="post-metadata">

**Author:** ![Xinchao](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/xinchao/32/6490_2.png) [@Xinchao](https://discuss.gradle.org/u/Xinchao)\
**Post date:** [September 24, 2018, 7:29am UTC](https://discuss.gradle.org/t/use-a-task-for-dependency-locking/28657/4 "2018-09-24T07:29:26Z")

</div>

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:

```gradle
assert gradle.startParameter.writeDependencyLocks

```

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

```gradle
gradle resolveAndLockAll --write-lock

```

---

<div class="post-metadata">

**Author:** ![ljacomet](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/ljacomet/32/11907_2.png) [@ljacomet](https://discuss.gradle.org/u/ljacomet)\
**Post date:** [February 19, 2019, 12:45pm UTC](https://discuss.gradle.org/t/use-a-task-for-dependency-locking/28657/6 "2019-02-19T12:45:53Z")

</div>

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.