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.)
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.
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.)
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.