Allow custom edit/view links in CatalogTable rows

Feature Suggestion

The catalog table includes edit and view links. Make these customisable on a per location basis.

Possible Implementation

This could be added to the various schemas for locations, in app-config.yaml for example:

locations:
  - type: url
    target: https://github.com/example/example/blob/master/catalog-info.yaml
    editUrl: https://github.com/example/example/edit/master/catalog/index.jsonnet

The explicit URLs would then override the link builder functions in the catalog plugin.

export const createEditLink = (location: LocationSpec): string | undefined => {
  if (location.editUrl) return location.editUrl;
  // ... existing implementation goes here ... 
}

Context

The current implementation works reliably if:

1. You are using one of the supported Git providers to store your catalog manifests
2. The YAML file itself is the source of truth, ie, it is not generated from other source files

If the first condition is not true, then edit/view links may or may not take the user to the right place. For example, we have a custom catalog processor that reads from a GCS bucket, and in that case the links take you to a browser-unfriendly gs:// url.

If the second condition is not true, then you may inadvertently send users to edit generated files, which is not ideal.

Allowing customisation would prevent these problems. Doing it per location would seem to be the best idea since these links are tied to the particular implementation of the location’s target.

[tragiclifestories]

I’ve been meaning to make an RFC for supporting cloud storage providers - there was a slightly frosty reception for the idea in Discord but I think it’s probably worth discussing more elsewhere.

I take the point that allowing the link builders to be replaced would be a possible alternative implementation - I just wrote down the first one that came to me. It also occurs to me that I often wish that a particular link or button did something slightly different and so it might be worth coming up with a mechanism for these things that is ‘generalisable’ in some sense.

[freben]

Also it could be a decent convention to put the yaml files where the actual module is instead of in the root. And then you could register a glob url to capture them all in one go!

<...>/**/catalog-info.yaml