Is there a way to control the order of tasks?

[suin]

First, I want to thank you for creating such a fantastic tool!

I created the following moon.yml and ran moon run reset -c 1 --cache off:

tasks:
  build:
    local: true
    deps:
      - build-1
      - build-2
    options:
      runDepsInParallel: false
      persistent: false

  build-1:
    command: node -e 'setTimeout(() => console.log("build-1 done"), 200)'

  build-2:
    command: node -e 'setTimeout(() => console.log("build-1 done"), 200)'

  clean:
    command: node -e 'setTimeout(() => console.log("clean done"), 300)'
    local: true
    options:
      persistent: false

  reset:
    deps:
      - clean
      - build
    local: true
    options:
      runDepsInParallel: false
      persistent: false

I expected the tasks to run in the following order:

1. clean
2. build-1
3. build-2
4. build

However, the actual order was:

1. build-1
2. clean
3. build-2
4. build

From the action graph , it appears that clean and build-1 & build-2 are running concurrently.

While the reset task can control its direct dependencies (clean and build) with runDepsInParallel, is there a way for the reset task to control the execution timing of its nested dependencies (build-1 and build-2) to ensure they run after clean?

[suin]

I found a workaround for my question:

reset:
  command: "$SHELL -c 'moon run clean && moon run build'"
  local: true
  options:
    persistent: false
    shell: false

If there are any other methods to achieve the same result, I would love to hear them. Thank you!

[milesj]

Yeah this is "incomplete" at the moment. The runDepsInParallel option only applies to direct deps, so transient deps don't follow the dependency chain, and the graph considers them parallel.

There's a few issues about this currently, but it's a really hard problem to solve.

[anotheri]

it seems we can use mutex to avoid running tasks in parallel? but the order is still not guaranteed, correct?
what if use combination of mutex and some additional option for order?
i've tried to combine mutex and priority options as workaround and it works (at least if i define priority for both tasks as low and high, but it's quite limited to 2-3 tasks)

[milesj]

Yeah there's no way to control the order besides priority, because topological sort takes precedence.