# Alternative pattern to deal with special checkout/clean/init type tasks

**URL:** <https://discuss.gradle.org/t/alternative-pattern-to-deal-with-special-checkout-clean-init-type-tasks/5366>\
**Category:** Old Forum Archive\
**Created:** [April 6, 2012, 1:13am UTC](https://discuss.gradle.org/t/alternative-pattern-to-deal-with-special-checkout-clean-init-type-tasks/5366 "2012-04-06T01:13:00Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Spencer\_Allain](https://avatars.discourse-cdn.com/v4/letter/s/7ba0ec/32.png) [@Spencer\_Allain](https://discuss.gradle.org/u/Spencer_Allain)\
**Post date:** [April 6, 2012, 1:13am UTC](https://discuss.gradle.org/t/alternative-pattern-to-deal-with-special-checkout-clean-init-type-tasks/5366/1 "2012-04-06T01:13:00Z")

</div>

doing “gradle init release” from the command line does exactly what one wants, but ideally you want to programmatically have “gradle release” call “init” before any other dependent tasks would ever get invoked.

Technically it seems possible that the task graph can be constructed, examined, and then the exact nodes to descend from could be selectable before execution actually occurs (akin to what happens to the startParameter.taskNames gets mapped to internally).

Below shows what can be done with a project variable (could as easily be a system variable) and a failed attempt at trying to change the tasks to execute after the task graph is ready.

```gradle
task init { doLast { println 'init' }}
  task release {
  // Works, but not ideal
  if (project.hasProperty('doRelease')) {
    project.gradle.startParameter.taskNames = ['init'] +
      project.gradle.startParameter.taskNames
  }
}
  gradle.taskGraph.whenReady { graph ->
  // Too late
  if (graph.hasTask(':release')) {
    project.gradle.startParameter.taskNames = ['init'] +
      project.gradle.startParameter.taskNames
  }
}

```

I’ve not considered all the possible side effects, but it seems that marking the fixed order of the nodes where depth-first execution searches start from is already possible from the command line, and this would simply be exposing that capability to the build scripts after the DAG is ready (it would not attempt to change any links in the graph, just essentially provide the ordered list of nodes to start working from).

-Spencer

---

<div class="post-metadata">

**Author:** ![Andrew\_Oberstar](https://avatars.discourse-cdn.com/v4/letter/a/8dc957/32.png) [@Andrew\_Oberstar](https://discuss.gradle.org/u/Andrew_Oberstar)\
**Post date:** [April 6, 2012, 1:56am UTC](https://discuss.gradle.org/t/alternative-pattern-to-deal-with-special-checkout-clean-init-type-tasks/5366/2 "2012-04-06T01:56:00Z")

</div>

How about something like this?

```gradle
task init << { println 'init' }
  gradle.taskGraph.whenReady { graph ->
  init.onlyIf { graph.hasTask(':release') }
}

```

You’d still have to do something to make sure the init task ran first, though…

---

<div class="post-metadata">

**Author:** ![Peter\_Niederwieser](https://avatars.discourse-cdn.com/v4/letter/p/9f8e36/32.png) [@Peter\_Niederwieser](https://discuss.gradle.org/u/Peter_Niederwieser)\
**Post date:** [April 6, 2012, 2:31am UTC](https://discuss.gradle.org/t/alternative-pattern-to-deal-with-special-checkout-clean-init-type-tasks/5366/3 "2012-04-06T02:31:00Z")

</div>

@Spencer: Sounds like a good thing to have. Besides that, I think we also need a way to inspect the task graph and still make changes to it (like adding dependencies). tI’m envisioning a two-pass algorithm with ‘whenPrepared’ and ‘whenReady’ callbacks.

---

<div class="post-metadata">

**Author:** ![matzepfau](https://avatars.discourse-cdn.com/v4/letter/m/94ad74/32.png) [@matzepfau](https://discuss.gradle.org/u/matzepfau)\
**Post date:** [April 27, 2012, 11:06am UTC](https://discuss.gradle.org/t/alternative-pattern-to-deal-with-special-checkout-clean-init-type-tasks/5366/4 "2012-04-27T11:06:00Z")

</div>

@Peter: That’ exactly what we need, too.