chore: align manifest images

[tarilabs]

No description provided.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: tarilabs

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• manifests/kustomize/OWNERS [tarilabs]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.58%. Comparing base (d9a2e20) to head (69f71bc).

Additional details and impacted files

@@               Coverage Diff               @@
##           release/v0.2.8     #131   +/-   ##
===============================================
  Coverage           77.58%   77.58%           
===============================================
  Files                  24       24           
  Lines                2159     2159           
  Branches              145      145           
===============================================
  Hits                 1675     1675           
  Misses                287      287           
  Partials              197      197           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tarilabs]

note: build job successfull (the one doing unit, integration) and same for python testing.
job build-and-test-image (dry-run the operator successfully deploy an instance of MR) failed which currently expect a Model Registry Operator branch, but that can only happen after a release of operator, which wants the Model Registry image.

...seems to me a circular dependency issue.

I propose to move the GHA job build-and-test-image to the Model Registry Operator,
or alternatively to amend the current GHA job build-and-test-image to use the main branche from MR Operator.

cc @Al-Pragliola what is your pov here?

since the job build-and-test-image is mainly to dry-run the operator deploys the image, proceeding anyway with the release, since testing is done both upstream and unit, integration testing with the other GHA jobs

[Al-Pragliola]

Absolutely, I agree with you @tarilabs that the MR operator is dependent on the MR. So I think it is wrong to do the integration test here in MR, I would also move it to the operator. If we want to avoid the scenario where we release MR v0.x.y and then see that it breaks with the MR operator and we have to re-release or bump to MR v0.x.y+1, we can include the use of RCs in both repos and then when everything is green do the release.

[tarilabs]

this is a great idea @Al-Pragliola thank you for the suggestion.

As discussed offline, for the next time, I will do branching "at once" in both repos. Since we release from main, this is possibly a simple way to test this.

Can always opt for RC strategy when we have some changes that requires attention in the interaction between the operator and MR.