Skip to content

0.19.26

Choose a tag to compare

@r4victor r4victor released this 28 Aug 11:00
· 491 commits to master since this release
2c47e64

Repos

Previously, dstack always required running the dstack init command before use. This also meant that dstack would always mount the current folder as a repo.

With this update, repo configuration is now explicit and declarative. If you want to use a repo in your run, you must specify it with the new repos property. The dstack init command is now only used to provide custom Git credentials when working with private repos.

For example, imagine you have a cloned Git repo with an examples subdirectory containing a .dstack.yml file:

type: dev-environment
name: vscode    

repos:
  # Mounts the parent directory of `examples` (must be a Git repo)
  #   to `/workflow` (the default working directory)
  - ..

ide: vscode

When you run this configuration, dstack fetches the repo on the instance, applies your local changes, and mounts it—so the container always matches your local repo.

Sometimes you may want to mount a Git repo without cloning it locally. In that case, simply provide a URL in repos:

type: dev-environment
name: vscode    

repos:
  # Clone the specified repo to `/workflow` (the default working directory)
  - https://github.com/dstackai/dstack

ide: vscode

If the repo is private, dstack will automatically try to use your default Git credentials (from ~/.ssh/config or ~/.config/gh/hosts.yml).

To configure custom Git credentials, use dstack init.

Note

If you previously initialized a repo via dstack init, it will still be mounted. Be sure to migrate to repos, as implicitly configured repos are deprecated and will stop working in future releases.

If you no longer want to use the implicitly configured repo, run dstack init --remove.

Note

Currently, you can configure only one repo per run configuration.

Fleets

Previously, when dstack added new instances to existing fleets, it ignored the fleet configuration and used only the run configuration for which the instance was created. This could result in fleets containing instances that didn’t match their configuration.

This has now been fixed: fleet configurations and run configurations are intersected so that provisioned instances respect both. For example, given a fleet configuration:

type: fleet
name: cloud-fleet
placement: any
nodes: 0..2
backends:
  - runpod

and a run configuration:

type: dev-environment
ide: vscode
spot_policy: spot
fleets:
  - cloud-fleet

dstack will provision a RunPod spot instance in cloud-fleet.

This change lets you define main provisioning parameters in fleet configurations, while adjusting them in run configurations as needed.

Note

Currently, the run plan does not take fleet configuration into account when showing offers, since the target fleet may not be known beforehand. We plan to improve this by showing offers for all candidate fleets.

Examples

Wan2.2

We've added a new example demonstrating how to use Wan2.2, the new open-source SOTA text-to-video model, to generate videos.

Internals

Pyright integration

We now use pyright for type checking dstack Python code in CI. If you contribute to dstack, we recommend you configure your IDE to use pyright/pylance with standard type checking mode.

What's changed

Full changelog: 0.19.25...0.19.26