Backend: Update the releases logic in catalog resources to use the Version association
Summary
The following discussion from #429279 (comment 1620838016) should be addressed.
@fabiopitino: The GraphQLResourceType#versionsandlatest_versioncurrently return aTypes::ReleaseTypebecause that's what we have until we create records incatalog_resource_versionstable. At that point we should only pull data fromCatalog::Resource#versionsassociation and not releases.I'm noticing actually that we have
versionsandlatest_versionmethods inCatalog::Resourcethat return releases. These need to be changed to use the association. Thehas_many :versionsassociation I think is not currently used because theversionsmethod overrides that.
@lma-git: Yes, as far as I'm aware, the intention was to convert Release to Version after we establishedcatalog_resource_versionsand related processes. I think the conversion needs to be a VerifyP1 issue that follows Backend: Scan a catalog resource for components (#415413 - closed), if it's not already created. cc@lauraX@avielleWe'll likely need to do something like the
Release.latest_for_projectsquery for theVersionmodel. This query is efficient because we provide a set # of projects and only return 1 release per project.However, with Versions, we'll inevitably have to join
catalog_resource_versionswithreleases, and I think we'll face the same query performance problems as we have with joiningcatalog_resourcesandprojects.
Proposal
- Update the releases logic in the
Ci::Catalog::Resourcemodel to use the Versions association. - Update the
Ci::Catalog::Resources::Versionmodel so that it has similar methods as theReleasemodel, adapted for Versions. - Update the resolver logic for the GraphQl fields
versionsandlatest_versionsin ResourceType to use Versions. (This will likely involve creating a newCi::Catalog::Resources::VersionsFinderfinder class.) - Update
InstancePathto use the latest Version if the project is a catalog resource.