Unable to generate or upload relations when `POST`-ing entities to the catalog-backend.

The route handling function for POST /entities in the catalog-backend disregards relations POST-ed in the request and also does not generate relationships, when an Entity is posted.

Expected Behavior

Either relationships should be allowed to be injected manually, or auto-generated, such as done in the BuiltinKindsEntityProcessor

Current Behavior

Relationships are not generated, or allowed when POST-ing entities. The lack of relationships affects a lot of UI features, for example, to jump to the Group that owns a Component on the Catalog. This makes Locations the only functioning way to inject entities into the catalog database with relations.

Possible Solution

1. Allow relations to be POST-ed along with entities.
2. Generate entity relations before add entites to the database.

This could involve splitting out the logic to generation relations into a separate function that can then be re-used in the Kinds and the

Steps to Reproduce

Post an Entity of kind Group with an arbitrary name a. Post an Entity of kind Component with name Alpha with spec.owner set to a.

No ownedBy relation for Alpha is generated with target to {default, Group A}.

The catalog UI plugin’s overview does not link to a for Alpha due to the missing relationship.

Context

I was trying to generate entities from an existing service by POST-ing to the catalog backend and the UI did not show the relationships as expected. On further inspection and reading the code, it looks like relation ships are not generated (and ignored, if present in the payload) when entities are directly POSTED to the catalog.

Your Environment

• NodeJS Version (v12):
• Operating System and Version (e.g. Ubuntu 14.04):
• Browser Information:

[freben]

Hi! Yeah we are very interested in getting an event driven architecture into place, what you describe is accurate from an end user perspective. We will see if it in practice is solved like this though, or in some other manner. For example, an alternative solution could be a webhook driver that marks locations dirty and then those get pulled in from the catalog side instead.

We’ll be working on the catalog this quarter, and then we’ll dissect the processing loop and see what we can do about things. To make processing truly deterministic, we need to make sure that things that have requirements on their surroundings are in place. For example, to have proper resolution of relations with other entities, it may not be enough to “know of” only the local entity itself; you may need to be able to access a context around you too. This is where the mismatch between the “push” and “pull” models come into play.

But yeah, we’ll look at that for sure.

[martina-if]

Hi @freben I was thinking about this and imagine there was a GHA that whenever a PR is open would check that the catalog-info.yaml file is valid and then when the PR gets merged it would push its entities to Backstage. Wouldn’t this endpoint be useful in that case? Or would that be done through a different one?