Running other tasks from a task

[Jérôme Vizcaino]

Context

As a user, I would like to declare a task that calls other orbit task. Since the orbit.yml is templated, this makes it hard to call orbit again with the same calling parameters.

Example: orbit is run using orbit run -p Tasks,tasks.yml -f ../shared-orbit.yml <task_name>

In order to call other tasks from a given task, I would have to copy/paste that line which is far from ideal since it implies the task as knowledge of how it gets called.

Proposal

Add a tasks entry to refer to other tasks in the current file.
In order to remove confusion, either tasks or run should be provided, not both, otherwise order of command execution would be unknown.

tasks:
{{ range $app := .Orbit.Tasks }}
  - use: {{ $app }}
    tasks:
    - {{ $app }}:render
    - {{ $app }}:upload
  - use: {{ $app }}:render
    run:
     - echo "{{$app }}: render step"
  - use: {{ $app }}:upload
    run:
     - echo "{{ $app }}: upload step"
{{ end }}

Now, with a tasks.yml with the following content

- foo
- bar

Running orbit run -p Tasks,tasks.yml foo bar should print

foo: render step
foo: upload step
bar: render step
bar: upload step

Your Environment

• Version used (orbit version): 3.0.1

Thanks for writing this app, it has been super useful so far 👍

[Julien Neuhart]

Hi @j-vizcaino!

With the following orbit.yml file:

tasks:
{{ range $app := .Orbit.Tasks }}
  - use: {{ $app }}
    run:
    - orbit run {{ $app }}:render
    - orbit run {{ $app }}:upload
  - use: {{ $app }}:render
    run:
     - echo "{{$app }}: render step"
  - use: {{ $app }}:upload
    run:
     - echo "{{ $app }}: upload step"
{{ end }}

And the payload file orbit-payload.yml:

payload:
  - key: Tasks
  - value: tasks.yml

You could run orbit run foo bar which should give you the expected behaviour.

Still, being able to call others tasks within the same context could make sense. I'll consider it for the next 3.1.0 release 😃

[Jérôme Vizcaino]

Thanks for quick answer! That's right, the example you provided works and will unblock me for the time being.

Though, this example makes the following assumptions:

• orbit is in your PATH
• orbit run was run without any other argument

Running the "subtasks" in the same context would allow for proper composition of tasks and consistency of, say debug flag.

[Julien Neuhart]

Sooo after trying to implement a solution, I've discovered that the text/template allows the following:

{{ define "render" }}
      - echo {{ . }}
{{ end }}

{{ define "upload" }}
      - echo {{ . }}
{{ end }}

tasks:
  {{ range $app := .Orbit.Tasks }}
  - use: {{ $app }}
    run:
    {{ template "render" $app }}
    {{ template "upload" $app }}

  - use: {{ $app }}:render
    run:
    {{ template "render" $app }}

  - use: {{ $app }}:upload
    run:
    {{ template "upload" $app }}
{{ end }}

Thanks to templating goodness, you may now run orbit run foo bar -p "Tasks,tasks.yml"!

I've just tested it and the command returned the following:

foo
foo
bar
bar

Important: make sure you have a correct indentation in your templates.

[Julien Neuhart]

I'll update the documentation to show this case.

[Jérôme Vizcaino]

That's an interesting option, I did not think about define.

The thing is, I'm not sure this will play out well when dealing with generated tasks and, as you noted, this feels a bit hacky because of the indent 🤔 Further more, this hides from the end-user the fact that tasks calls other tasks (I like how make shows this)

I will try to post the exact example that pushed me into opening this use-case: this will surely help better understanding the expected result.

[Julien Neuhart]

Indeed, it feels a bit hacky 😄 but what I like is the use of text/template possibilities to handle such case.

That's said, it could be nice to be able to have an orbit.yml file like this:

tasks:
  
  - use: myTask
     run:
       - {{ run('subtask1', 'subtask2') }}
       - cmd
       - cmd