Skip to content

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::InstancePath so 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.

  1. Check out the master branch.
  2. Create a catalog resource project.
  3. Add a component file to your catalog resource with the following content.

templates/component1.yml

component1:
  script: echo
  1. In your .gitlab-ci.yml file, update the content to the following. Update the path as necessary:
include:
  - component: gdk.test:3000/group-a/catalog-resource-1/component1@~latest
  1. Update your templates/component1.yml file so that the script is echo 1 and commit it to a new branch named branch1.
  2. Now update that same file with echo 2 and commit it to a new branch named branch2.
  3. Create tags for both branches named tag1 and tag2, respectively. Then create corresponding releases (ensure the release date of tag2 is later than tag1.
  4. In the Pipeline editor's "Full configuration" tab, observe that the output shows echo 2 (the change from the latest release).

Screenshot_2023-11-01_at_2.16.01_PM

  1. Check out this branch (and restart gdk).
  2. 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.

Related to #429707 (closed)

Edited by Leaminn Ma

Merge request reports