# Gradle task that checks if \`build\` is up-to-date?

**URL:** <https://discuss.gradle.org/t/gradle-task-that-checks-if-build-is-up-to-date/45386>\
**Category:** Help/Discuss\
**Created:** [April 15, 2023, 12:06pm UTC](https://discuss.gradle.org/t/gradle-task-that-checks-if-build-is-up-to-date/45386 "2023-04-15T12:06:57Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![eekboom](https://avatars.discourse-cdn.com/v4/letter/e/35a633/32.png) [@eekboom](https://discuss.gradle.org/u/eekboom)\
**Post date:** [April 15, 2023, 12:06pm UTC](https://discuss.gradle.org/t/gradle-task-that-checks-if-build-is-up-to-date/45386/1 "2023-04-15T12:06:57Z")

</div>

After I have executed `build` once, then directly execute `build` again, a well-written build script should not actually run any tasks, right? (So, all actionable tasks on the second invocation should give “UP-TO-DATE”).

However, in my experience with people adding features to the build over time, the build deteriorates and some tasks sneak in, that will get needlessly executed _every_ time (and will probably trigger execution of other tasks that depend on them).

So: Is it possible to write a new task `verifyUptodate` that checks if all tasks depending on `build` are up-to-date?  
(That way I could add execution of that task to Jenkins (after build has run) and have it fail the Jenkins build, so this mis-configured build would be detected before landing on main.)

---

<div class="post-metadata">

**Author:** ![Vampire](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/vampire/32/9082_2.png) [@Vampire](https://discuss.gradle.org/u/Vampire)\
**Post date:** [April 15, 2023, 6:04pm UTC](https://discuss.gradle.org/t/gradle-task-that-checks-if-build-is-up-to-date/45386/2 "2023-04-15T18:04:27Z")

</div>

No, not necessarily all tasks will be up to date.  
There could well be legal cases of tasks that are never up to date but are executed always.  
If you want nevertheless such a check, the cleanest solution would probably be an `org.gradle.tooling.events.OperationCompletionListener` that you register with a `org.gradle.build.event.BuildEventsListenerRegistry`, where you then can check whether the tasks were successful and whether they were up-to-date.

---

<div class="post-metadata">

**Author:** ![eekboom](https://avatars.discourse-cdn.com/v4/letter/e/35a633/32.png) [@eekboom](https://discuss.gradle.org/u/eekboom)\
**Post date:** [April 16, 2023, 6:33pm UTC](https://discuss.gradle.org/t/gradle-task-that-checks-if-build-is-up-to-date/45386/3 "2023-04-16T18:33:50Z")

</div>

Thanks for the answer, I’ll try that.

Out of curiosity: What may be “legal” reasons for tasks that are executed always and that `build` depends upon?  
Isn’t that a scenario that would cause builds to not be reproducible?

(I get that there may be other tasks that should run always, but where `build` does not depend upon these tasks.)

---

<div class="post-metadata">

**Author:** ![Vampire](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/vampire/32/9082_2.png) [@Vampire](https://discuss.gradle.org/u/Vampire)\
**Post date:** [April 16, 2023, 8:48pm UTC](https://discuss.gradle.org/t/gradle-task-that-checks-if-build-is-up-to-date/45386/4 "2023-04-16T20:48:25Z")

</div>

Just one example out of many.  
`build` depends on `check`.  
`check` depends on various check and test tasks, and might for example depend on `integTest`.  
`integTest` might depend on some external state like a database or some test definintions or whatever.  
This might require the task to always run.

Or a task maybe does not have _file_ outputs and thus can never be up-to-date or cached.

There are many legal possibilities.  
Whether this makes a build non-reproducible or not can be true or false, depending on the details.