On Tue, Jun 25, 2013 at 5:57 AM, Adam Murdoch
<adam.murd...@gradleware.com>wrote:
>
> This is merged now.
>
Got super excited and wanted to try it out using a nightly build but got it
to throw an IndexOutOfBoundsException when:
- b depends on a
- a is finalized by c
- b is finalized by c
Just the regular start server -> run integration test -> shutdown server
scenario... This is really bad, wonder how I got such a common use case
wrong, the coverage seemed to be really good, yet it still happened. I will
work on a pull request for that tonight.
>
> @Marcin, are you interested in adding support for 'shouldRunAfter' task
> rules, to round things out?
>
> The main use case for this is to provide feedback as early as possible
> during the build without adding any constraints on execution. Some examples:
>
> * run static analysis before tests
> * run unit tests before integration tests
> * run the unit tests for a project before compiling those projects that
> depend on it
>
> The idea is to add a very weak task execution rule that only provides
> hints for execution order and implies nothing else. So, if A shouldRunAfter
> B then:
>
> 1. If A or B are not scheduled to run, ignore the rule.
> 2. Run A after B only if there are no other contradictory rules on the
> ordering of A and B. That is, ignore cycles introduced by shouldRunAfter
> rules.
> 3. The dependencies of A shouldRunAfter B and its dependencies.
> 4. If B fails or is not run, A can still be run.
> 5. If there is an idle worker thread and A is the only task whose
> dependencies have been satisfied, then run A regardless of whether B has
> been run or not. That is, prefer running the task over an idle worker
> thread.
>
> Similar to mustRunAfter, but different in #2 and #5 above.
>
> There are plenty of other things we could also do with the task rules, if
> you're interested in any of this:
>
> * Move the task rules to a specific namespace rather than have the methods
> directly on Task.
> * Change Ant import to use shouldRunAfter to emulate Ant's target ordering
> rules.
> * Improve finaliser support for tasks that are skipped. For example, if a
> SourceTask has no source files, then don't run the finalisers for this task.
> * Add a replacement for Task.enabled that does not run any of the
> dependencies of the task that are not otherwise required.
> * Add conveniences to declare rules like 'shouldRunLast',
> 'mustRunAsEarlyAsPossible', and so on that work on groups of tasks.
> * Handle setting up and tearing down test resources as required. For
> example, create a database instance and start the web container if the
> integration tests are to be run, and clean everything up when finished with
> them.
> * Add resource usage aware parallel task scheduling. For example, don't
> run two integration test suites in parallel if they both need exclusive
> access to the database instance.
> * Add input and output file aware parallel task scheduling. For example,
> don't run the clean and compile tasks in parallel.
> * Add support for using the output of a project to configure another
> project, so that we schedule some tasks, run them, configure some things,
> then schedule and run more tasks.
> * Add a replacement for `gradle.taskGraph.whenReady {}` that is evaluated
> early in the configuration phase rather than at the end.
> * …
>
Thanks for the writeup Adam. Feels like shouldRunAfter is a natural
continuation of my work around the area of task scheduling so I'll stick to
and have a crack at it whenever I have a spare evening.
