Skip to main content

working_directory

The step-level working_directory field overrides the workflow-level working directory for a single step.

workflows:
  download-and-install:
    working_directory: !repo-root
    steps:
      - command: wget https://example.com/archive.tar.gz
        working_directory: /tmp
        type: shell
      - command: make install
        type: shell

Use step-level working_directory for commands that need a different current directory from the rest of the workflow.

When a workflow-level container sandbox is active, Atmos resolves the path on the host and maps it into the container workspace before execution.

Path Resolution​

Path resolution differs by step type:

  • A type: shell, type: exec, or type: atmos step's working_directory — like the workflow-level default it can override — resolves a relative value against the Atmos base_path, whether or not it starts with ./.
  • An extended step type (for example archive, file, junit, workdir, or container) resolves its own working_directory against the current working directory instead, whether or not it starts with ./. If the step leaves working_directory unset, it still falls back to the workflow-level default (base_path-resolved) before falling back further to the current working directory.

There is no component-relative resolution here, since a workflow step isn't necessarily scoped to a single component. A kind: step hook resolves a plain relative value (no ./ prefix), or an unset working_directory, against the component's own working directory instead, and a dot-prefixed value (., .., ./x, ../x) against the current working directory — see that page for the full rule.

After working_directory is resolved, relative handler fields such as source, destination, path, files, and context resolve against that directory. For container builds, Dockerfile resolves relative to the resolved context, not directly to working_directory.