Update component InstancePath to use latest Version for Catalog Resource
What does this MR do and why?
Background:
With !134148 (merged), a catalog resource Version is created upon Release creation if the commit has valid components. A Version is essentially a Release in the context of catalog resources. The table catalog_resource_versions has a 1:1 relationship with releases.
So far, we have been using project Releases as the logic for Versions. Now we need to replace the logic from catalog_resource.project.releases to catalog_resource.versions.
This is MR #3 of 3 MRs to handle the logic migration.
This MR:
- Updates
Ci::Components::InstancePathso that when the project is a catalog resource, it returns the latest version rather than the latest release.
Resolves #429707 (closed)
How to set up and validate locally
Before checking out this branch, we should ensure the ~latest behaviour has not changed by comparing the outputs before and after.
- Check out the
masterbranch. - Create a catalog resource project.
- Add a component file to your catalog resource with the following content.
templates/component1.yml
component1:
script: echo
- In your
.gitlab-ci.ymlfile, update the content to the following. Update the path as necessary:
include:
- component: gdk.test:3000/group-a/catalog-resource-1/component1@~latest
- Update your
templates/component1.ymlfile so that the script isecho 1and commit it to a new branch namedbranch1. - Now update that same file with
echo 2and commit it to a new branch namedbranch2. - Create tags for both branches named
tag1andtag2, respectively. Then create corresponding releases (ensure the release date oftag2is later thantag1. - In the Pipeline editor's "Full configuration" tab, observe that the output shows
echo 2(the change from the latest release).
- Check out this branch (and restart gdk).
- Refresh the Pipeline editor and observe the output is the same as it was in Step 8.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #429707 (closed)
