[dagit] Repair repo specificity on Run details and re-execution
Identical pipelines in separate repositories can have identical snapshots. This means that depending on snapshot ID as our best bet for identifying the right pipeline to re-execute is often going to be incorrect when repositories have identical pipelines, as in the associated GH issue.
Try to improve upon this by using the repository origin of the PipelineRun.
- If the origin *and* snapshot are a match, that's basically the best we can do. Don't display any warning messages, and use this match for re-execution.
- If only the origin is a match, it's possible that the pipeline/job in the workspace is now out of date vis-a-vis the version of the pipeline/job from the run. Show a warning message, but use this repo for re-execution.
- If only the snapshot is a match, then the repo from the original run execution is not a match or might not be present in the active workspace. Show a warning message. For re-execution, use the first repo that matches the snapshot, since we can't disambiguate among the repos that contain that snapshot.
- If only the pipeline/job name is a match, then we're just going to have to go with that. Show a warning message, and use the first repo that matches the pipeline/job name, since we can't disambiguate among the repos that contain that pipeline/job.
This change also makes use of the repository information on the PipelineRun to provide a better link to the pipeline/job name in the Run header.
Test Plan: View a workspace with two repos that have identical jobs (and therefore identical snapshots). Verify that when I re-execute jobs, they make use of the correct repository information.
Reviewers: bengotow, prha, yuhan
Reviewed By: yuhan
Differential Revision: https://dagster.phacility.com/D9144