I have a main repository and on merge requests sta...
# ask-community
r
I have a main repository and on merge requests start a new repository (with a different name) but both end up connected to the same dagit instance. They contain similar but slightly different code. However when I look at a sensor it mentions the same last run. Is it possible to keep runs / jobs / ops from different repositories apart from eachother? They seem to bleed into each other. When I look into the runs of one job I see the runs from the job with the same name in another repository
1
y
Hi Roel, to each jobs and ops from different repositories apart from each other, you can have different definitions of them in the different repositories. but if you reuse these definitions, the same definitions will be referenced by different repositories. to keep runs apart, you may need to use/deploy different Dagster Instances, because runs live in Run Storage which is tied to one Dagster Instance - cc @daniel plz correct me if im wrong.
r
Alright Thanks for this clarification@yuhan! In my mental model of dagster the repository was completely isolated from the other components (dagit and daemon and database) so I have to adjust a bit.
I would expect jobs and ops to be part of a repository and therefore isolated from other repositories.
you can have different definitions of them in the different repositories. but if you reuse these definitions, the same definitions will be referenced by different repositories.
This is the key point I did not understand ☝️
Thanks!
d
@Roel Hogervorst the specific issue you mentioned about jobs with the same name in different repositories having the same list of runs (or sensors with the same name having the same last run or list of runs) sounds like a known bug to me: https://github.com/dagster-io/dagster/issues/6725 - @prha is just about to squash that one I believe.
🎉 1
r
oooh! Yes that is exactly my issue!
p
Hi Roel. I have a couple of open PRs that should switch this behavior for the repository-scoped views, along with a data migration to enable the correct historical data to be populated. Hoping to land this in time for next week’s release.
r
awesome!