Run other commands

[kool2zero]

What are you trying to do?

This might be a stupid question. I have a few processes where I need to run a TI, then run an ETL (using cmd line), then run a DB command (using cmd line), then another TI.

Is there a way (or possible enhancement in the future), to be able to call local commands via Rush TI?

What have you tried?

No response

RushTI Version

No response

Additional Context

No response

[nicolasbisurgi]

hi @kool2zero - not a stupid question at all! We discussed this internally a couple of weeks ago and we all agree it should be feasible to implement.
We could expand it to execute tm1 chores as well as run command line arguments BUT only in the same machine in which rushti is running.
We need to make sure we have a proper way to capture the returns from the terminal and log them into the results of the workflow run.

Do you think the above would meet your expectations? Are there any other things you think we should add to it aside from terminal and chores?

[kool2zero]

For the most part, that 90% fits my use case but some other potential enhancements that might be neat:

• Reusable stages - I turn off a process (Stage A) that runs every 5 minutes. Then I run Stage B. I run Stage A to pick up data since the last time it ran. Then I run Stage C, then run Stage A again to pick up the Data. Run Stage D... etc. If in stage precedence I could do A -> B -> A -> C -> A -> D...
• Reusable task files - Being able to call other task files from within a task file. This could be used instead of (or in parallel) to the reusable stages.
• Call REST API - I don't necessarily use this but I could see it being used to kick off downstream processes in other systems.

Sidenote: Actually implementing this would be neat :) Maybe there is another tool that does something similar I don't know about :)

[nicolasbisurgi]

This was generated by AI during triage.

Scoping decision

After a design pass on the original ask, we're splitting #145 into two focused tickets covering the two execution surfaces with the strongest demand. The remaining ideas (REST, sub-taskfiles, reusable stages) are not being pursued at this time — happy to revisit if usage patterns surface a clear need later.

In scope (separate tickets):

1. Add TM1 chore as a first-class task kind (Issue A of #145 split) #156 — TM1 chore task kind (filed, foundational)
   Introduces the polymorphic task abstraction (process xor chore, with field-name as discriminator), pre-execution SINGLE_COMMIT checks for safe retry, and additive schema updates to }rushti.load.results and the SQLite stats DB.

2. Issue B — shell command task kind (to be filed; depends on Add TM1 chore as a first-class task kind (Issue A of #145 split) #156)
   Builds on the polymorphic abstraction landed by Add TM1 chore as a first-class task kind (Issue A of #145 split) #156. Will need its own security-review pass for cube-source acceptance — shell commands sourced from a shared TM1 cube would be a real RCE surface, so the default for that kind will be JSON-only unless an ADR justifies otherwise.

Not pursuing:

• REST API task kind
• Reusable / cross-taskfile invocation
• Reusable stages (stage label re-run mid-DAG)

These could be re-opened as separate issues if there's clear demand later. The current split keeps the abstraction work narrow and ships value incrementally.

#145 stays open as the umbrella tracking issue until both #156 and Issue B ship. Thanks for the original ask and the follow-up ideas — they all helped shape the scope.