Here’s an example of converting from repos to defnitions: https://github.com/dagster-io/dagster/pull/11135 - want to make sure there’s no disparities with your migration story here

Hmm, I think code location name was not changed. We named the original repository but maybe in the definitions we cannot give a name to a definition? In the UI, the code location was shown as

my_repo_name@my-code-location

but now it is

my-code-location

. Questions • The behavior described above (resetting schedules & sensors etc.) is expected when migrating originally named repositories to definitions? • If so, is there any workaround? ◦ I found create_repository_using_definitions_args, but is it a suitable for this use case? We only have one repository per definition. More details: I confirmed that code location name was unchanged by checking that the workspace.yaml file was not changed.

"load_from":
- "grpc_server":
    "host": "hota"
    "location_name": "my-code-location"
    "port": 3030

In a repository before definition migration fetches runs with following.

"variables": {
  "filter": {
    "pipelineName": "my_pipeline",
    "tags": [
      {
        "key": ".dagster/repository",
        "value": "my_repo_name@my-code-location"
      }
    ]
  },
  "limit": 26
}

The new code location filters runs with a slightly different condition, which I guess this is why we don't see past runs.

"variables": {
  "filter": {
    "pipelineName": "my_pipeline",
    "tags": [
      {
        "key": ".dagster/repository",
        "value": "__repository__@my-code-location"
      }
    ]
  },
  "limit": 26
}