⚠️ change catalog-specific URL from full path to API endpoint ref

[grokspawn]

change catalog-specific URL from full path to API endpoint ref

solves #427 and implements phase 1 of the CatalogD expandable interface.

This phase just moves from status.contentURL to status.urls.base, and will be used to provide reference to the catalog-specific API instead of the full path to JSONLines-formatted content, plus tests and documentation.

Signed-off-by: Jordan Keister jordan@nimblewidget.com

[codecov]

Codecov Report

Attention: Patch coverage is 58.33333% with 15 lines in your changes missing coverage. Please review.

Project coverage is 37.83%. Comparing base (d320249) to head (28e5fbb).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
api/core/v1alpha1/zz_generated.deepcopy.go	0.00%	14 Missing ⚠️
cmd/manager/main.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #429      +/-   ##
==========================================
- Coverage   38.36%   37.83%   -0.54%     
==========================================
  Files          15       15              
  Lines         941     1208     +267     
==========================================
+ Hits          361      457      +96     
- Misses        530      701     +171     
  Partials       50       50              

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

[grokspawn]

e2e/upgrade-e2e will not work right because this is a breaking API change and the test pulls the latest release tag. Until this PR merges and we release a new tag, this test will not pass.

[grokspawn]

Setting this WIP until after the RFC completes review, but it's ready for eyeballs so I don't think it belongs in a draft state.

[grokspawn]

There were some questions about whether we could change the api access from the form

<site>/catalogs/<catalog>/api/v1/all

to

<site>/api/v1/catalog

to provide the v1 raw FBC. I'm playing in that space right now to see if there's a quick path to this, since the most important part we were trying to get done was the shift of status.contentURL to status.baseURL so we could get the API review going.

Edit: a few of us met yesterday to discuss in depth, and we determined that the catalog-centric API approach was more conducive to near-future plans to add digest-level information. So we're sticking with the catalog-centric API.

[grokspawn]

Thanks again for the review passes folks!
I think I've made all the changes, but for your (and my) convenience I included all the resolutions in a separate commit. The merge queues already squash multiple commits, so hopefully this makes it easier for us all to audit the changes with no actual impact to the merge.
Many of the changes look simple but quickly balloon out to a bunch of fiddly updates.

[everettraven]

One minor thing in the readme. Other than that LGTM

[JoelSpeed]

You should add a "tombstone" representing this API field now that it has been removed, to prevent it being re-added as a different serialisation

If contentURL in the future was re-added as a struct, instead of string, this would break clients who expect to be able to unmarshal it as a string

[LalatenduMohanty]

We have discussed this and the general consensus is that we are not going to fix it as we have not released GA APIs upstream. Also we do not have many clients who uses OLM V1 (indirectly this API) . We have been communicating that these set of APIs are not stable till we release V1 GA APIs.