Repository navigation
Add missing optional directory property on the RunShell #1191
Description
Activity
@cdavernas any feedback from the SDK Net? @JBBianchi and from SDK TS?
- added 2 commits that reference this issue
on Sep 18, 2026 I don't think we should support explicitly setting the working directory.
While this is technically straightforward to implement in .NET (
ProcessStartInfo.WorkingDirectory), workflows are intended to remain portable and cross-platform. Allowing an arbitrary working directory would let workflow definitions depend on the directory layout of the environment in which they were authored, making them much easier to break when moved to another machine or platform (e.g. Windows vs. Linux).Scripts should instead resolve paths relative to portable locations exposed by the workflow runtime, such as the workflow/package directory, rather than relying on a user-defined working directory.
I don't think we should support explicitly setting the working directory.
While this is technically straightforward to implement in .NET (
ProcessStartInfo.WorkingDirectory), workflows are intended to remain portable and cross-platform. Allowing an arbitrary working directory would let workflow definitions depend on the directory layout of the environment in which they were authored, making them much easier to break when moved to another machine or platform (e.g. Windows vs. Linux).Scripts should instead resolve paths relative to portable locations exposed by the workflow runtime, such as the workflow/package directory, rather than relying on a user-defined working directory.
Well, your point kind of make sense, but the reality shows me that we can't avoid some environment particularities. I don't think some team will ever move bash scripts to run on windows, unless they got crazy :D
In my case I have more than 80 ETL projects in the server and about 3300 bash scripts being called daily by 210 workflows. and all of them uses bash's PWD in the beginning...
I had workaround some scripts to experiment, but modify all those scripts to a portable way is not viable.
The Windows vs. Linux example was probably a bit fallacious, I agree.
However, the underlying issue remains: even on the same platform, there is no guarantee that an arbitrary directory referenced by a workflow will exist on another system. Supporting an explicit working directory would therefore make the workflow dependent on the filesystem layout of the execution environment.
And once we introduce that dependency, we would likely also need to define additional behavior around it: should the directory be created if it does not exist? Should existing content be preserved or overwritten? What happens if permissions differ? etc.
For your particular case, I completely understand why changing thousands of existing scripts is not realistic. But I’m not sure the specification should introduce environment-specific filesystem assumptions primarily to accommodate existing deployments.
At worst, I would rather expose a small set of well-defined, portable runtime locations — for example the workflow/package directory — and have scripts resolve relative paths from there. That keeps the workflow contract predictable without requiring the engine to manage arbitrary filesystem state.
Hey @cdavernas, good morning.
I think you are missing an important detail:Shell and work directory is an Operation System (OS) concept.You don't need any additional behavior. It is not the role of a workflow engine to create directories or handle permissions. If the directory was passed and its not in the server, just failed like any other existing call.
I did some research with chatGpt:
Yes, both Linux and Windows have the concept of a process working/current directory, although the implementation and terminology differ. The important distinction is: The working directory is an OS process attribute. This is why the language APIs look so similar You can see the same abstraction across platforms: Language | API Java | ProcessBuilder.directory() .NET | ProcessStartInfo.WorkingDirectory Python | subprocess(..., cwd=...) Node.js | spawn(..., { cwd }) Go | exec.Cmd.Dir They’re essentially exposing the same OS-level requirement: Create child process │ ├── executable = ... │ ├── arguments = ... │ └── working directory = ...And this is why I’d separate these two concepts when designing your execution model: Executable ↓ How do I find the script? Working directory ↓ Where does the process execute from? ↓ Where do relative paths resolve? That distinction is useful regardless of whether the actual script is Bash, PowerShell, Python, Java, etc.You don't need any additional behavior. It is not the role of a workflow engine to create directories or handle permissions. If the directory was passed and it's not in the server, just fail like any other existing call.
That's precisely my point. 🙂
I completely agree that the workflow engine should not create directories or manage permissions. But as a consequence, I don't think a workflow definition should bind itself to arbitrary, environment-specific filesystem locations in the first place.
I agree that the working directory is an OS/process concept, and that virtually every process API exposes it. What I'm questioning is whether an arbitrary OS path should therefore become part of the portable workflow contract.
Those are two different things.
For example, nothing prevents an SDK/runtime from ultimately doing:
ProcessStartInfo.WorkingDirectory = ...The question is where that value comes from.
If the workflow contains something like
/opt/acme/etl/foo, then the workflow author is encoding knowledge about the execution environment. Move that workflow to another server - even another Linux server - where the layout is/srv/etl/foo, and it breaks.And saying "then it fails" is perfectly valid runtime behavior, but it also demonstrates that the workflow itself was not portable.
IMHO, the workflow author should ideally not have to care about those system-specific details. If a working directory is needed, I'd rather have it resolved from a well-defined portable location such as the workflow/package/workspace directory, or supplied/configured by the execution environment.
So I don't disagree that
cwdexists or that engines internally need to deal with it. I disagree that this necessarily means arbitrary host-specific paths should be encoded in the workflow specification.@cdavernas I don't think the portability here holds. The information in the workflow definition is essential for the shell/script execution and it's part of the OS API.
The directory could come from a
secretor aninputfrom the workflow as part of the requirements for running it. The same can be said about anything the definition holds: an HTTP server (what if the server is locally accessible from one env and not from the other I'm porting my workflow to?).So to port a workflow from one server/runtime to another would be part of this process to circunvent all the ecosystem around it, not just drop it from one to the other. Also, since we opened the spec to be able to run scripts, the milk has already spilled. One can have a
script: yq. If the new server does not haveyqinstalled, it will fail. So, according to your reasoning, that workflow won't be portable?In order to port such a workflow from one server to the other, one would have to create the working dir to run the scripts, install the packages, and so on.
Reacted by Cristiano Gavião- linked a pull request that will close this issueAdd directory property to RunShell #1193
on Sep 28, 2026 As discussed offline, we will add the working-dir property and the governance model documented here: #1194
Reacted by Charles d'Avernas and Cristiano Gavião- added 2 commits that reference this issue
on Sep 29, 2026 - added a commit that references this issue
on Oct 9, 2026
Metadata
Metadata
Assignees
Type
Projects
- Status
What would you like to be added?
Some shell scripts use the directory where they started (the working directory) to calculate other paths relative to it.
So, we can't always use the directory where the workflow application was started as the script's working directory. If we do, the script will fail.
Java's
java.lang.ProcessBuilderhas an explicit method for setting the working directory:directory(File directory), and I believe other languages also have something like this.Proposal(s):
No response
Alternative(s):
No response
Additional info:
No response
Community Notes