Preserve pipeline and project associations across job retry resets
What does this MR do and why?
Ci::RetryJobService intentionally resets the retried job and the new job to pick up fresh column values (retried, processed, status), but reset is aliased to reload in ApplicationRecord: an eager reload that also drops the association cache. Later access to pipeline, project, and namespace on those instances therefore re-queried rows that were already in memory.
This MR captures the pipeline before the resets and re-attaches the known pipeline and project instances afterwards. The re-attached records are the same rows the associations would reload (a retry never moves a job to another pipeline or project), so there is no behavior change — measured on the jobRetry GraphQL mutation with CI variables, this removes 3 SQL queries (93 → 90 in the progression measured on the proof of concept, see References).
No feature flag: the change re-attaches the very records the dropped association cache pointed at, with no new code path to de-risk.
Measurement
Extracted from the proof-of-concept MR (see References), where the full progression 101 → 78 is measured.
References
MR acceptance checklist
Evaluated against the MR acceptance checklist.