## From the parent epic: > The `Ci::PersistentRef` logic exists so that the runner always has a fetchable ref ([see original issue](https://gitlab.com/gitlab-org/gitlab/-/issues/14863)). But it is: > > * **Fallible:** There is a race between ref deletion and ref creation. When a pipeline completes, we delete the ref. But completion is not permanent. Manual job runs can move the pipeline back into a running status. And when a build starts, we try to resurrect it. The order of those events is not guaranteed, meaning that we may accidentally delete a ref that is still needed. > * **Redundant:** Git can fetch objects directly. These objects won't be garbage collected, because we create a keep-around ref for `pipeline.sha`. The persistent ref life cycle also creates unnecessary churn on Gitaly. There is a tremendous amount of refs being created and deleted all the time that we shouldn't need at all. > > ### Proposal > > Deprecate and phase out the use of `Ci::PersistentRef` in favour of fetching the SHA directly. ## This specific issue Will enable us to checkout a bare SHA and stop using the PersistentRef for our own CI. There is likely other usage of PersistentRef that will take us longer to fully remove, but by feature flagging our own internal usage, which is the only supported usage, we can reduce the overwhelming majority of Gitaly traffic that uses the `PersistentRef`. At that point, it will be clearer how much unsupported usage there is out there: https://gitlab.com/gitlab-org/gitlab/-/work_items/591478+s and we'll be able to make a plan for migrating people away from it and plan to stop creating the refs at all.