Is there still a one-Github-repository limit on branch deployments, or am I able to create branch deployments out code locations living in separate repositories?

There’s no enforced limit but you’d have to get creative to achieve this. How would you imagine it working? A change in repo A deploys the changed version of A and the latest stable version of B? A version of B from a matching branch name?

I think it'd be fine for the location to deploy on its own, without reference to other locations. A code location should be independent of other locations, even if it has cross-location asset dependencies (since you can stub (?) assets via SourceAssets). So basically, a change in Repo/Location A deploys a branch deployment for Location A, and a change in Repo/Location B deploys a branch deployment for Location B. That's essentially how it works if you use multiple repos now, except you only get 1 Location in your branch deployment.

You can add multiple locations to a branch deployment. You’d need to modify your CI scripts to do so. Most likely by making multiple

dagster-cloud workspace add-location

calls once the branch deployment is created. It’s still not entirely clear to me where you’d choose to source the locations from separate github repos from. It feels like a similar challenge to managing PRs when changes live across multiple repos.

The biggest example of this is having a dagster location in our

dbt

repo, and a separate

dagster-core

repo. It's useful to keep them separate because the Dagster code rarely actually changes in the dbt project, but the project definitions change at an entirely different cadence to the other repositories. If we had branch deployments, users could try running their new models via Dagster (for example).

In that example, you’d want to extend your

dbt

repo’s CI to also redeploy your

dagster-core

locations after the branch deployment is created.