[Feature]: Default `working_dir` to the image's working directory

[peterschmidt85]

Current behavior

• The working directory is hardcoded to /workflow unless the user sets it explicitly.
• dstack uses /workflow to clone the repo if the user hasn’t specified a path.
• If the user specifies a relative repo path, it is placed inside the working directory.
• Files do not use the legacy repo directory. If no path is specified, or if it’s relative, they are mounted inside the working directory.

Planned changes

• By default, use the image’s default working directory.
• In our default Docker image, Change the working directory from /workflow to the user home directory (e.g. /root). This is to ensure the user experience for the default and non-default Docker images is similar).

WIth the regard to repos

There are several variants:

Variant 1: Default repo path to $DSTACK_REPO_DIR

• If the user hasn’t specified a repo path, clone the repo into DSTACK_REPO_DIR (for now, keep /workflow which can be changed later). Allow the user to cd into this directory in commands (for example, cd $DSTACK_REPO_DIR).
• If the user specifies a relative repo path, mount the repo inside the working directory.
• If the user specifies any repo path, also save it to DSTACK_REPO_DIR.

Variant 2: Default repo path to <working dir>/<repo name>

• If the user hasn’t specified a repo path, clone the repo into<working dir>/<repo name> (simulating how git clone <repo url> works).
• If the user specifies a relative repo path, mount the repo inside the working directory.
• If the user specifies any repo path, also save it to DSTACK_REPO_DIR.

Variant 3: Forbid no repo path

• Always require a relative or absolute repo path
• If the user specifies a relative repo path, mount the repo inside the working directory.
• If the user specifies any repo path, also save it to DSTACK_REPO_DIR.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[peterschmidt85]

Updated the issue description.

I personally, vote for the Variant 2 as its semantics is very close to the semantics of the files - it creates a repo similarly to git clone repo url inside the working directory - and most importantly doesn't involve a magical $DSTACK_REPO_DIR.

I think it's totally fine to go with Variant 3 as the first step. Later, in the future, we can consider making the repo path optional.