Message while unregistering entity

[latent meteor]

HI
I have created a custom kind and I had created a catalog-info.yaml in a repo for testing. This was discovered by backstage. Since then, I have deleted that catalog-info.yaml file but the custom entity is still shown in the catalog. I went to manually unregister the enity and am getting the following message

"This entity does not seem to originate from a registered location. You therefore only have the option to delete it outright from the catalog."

But I do have an attached location entity to this custom entity. I shoudl mention that all my entities are auto discovered from our GitHub org thanks to the integration.

Related question, why is the entity not getting auto removed? My custom entity is auto discorvered though.

[night lark]

The provider does issue a full mutation

https://github.com/backstage/backstage/blob/ee411e7c262322f45ff156939925509da72c86a3/plugins/catalog-backend-module-github/src/providers/GithubEntityProvider.ts#L191

so indeed, i'd expect the next discovery run to not find the yaml file and the ensuing mutation to remove everything that's gone

https://github.com/backstage/backstage/blob/ee411e7c262322f45ff156939925509da72c86a3/plugins/catalog-backend/src/database/DefaultProviderDatabase.ts#L83

Hm. You're sure the provider is still running fine right? Do other entities get discovered still and their changes get reflected in the catalog?

[latent meteor]

The provider seems to be running fine as entities are getting discovered. Just for the sake of completeness, here's my catalog config

catalog:
  import:
    entityFilename: catalog-info.yaml
    pullRequestBranchName: backstage-integration
  rules:
    - allow: [Component, System, API, Resource, Location, Template, Project, Customer]
  providers:
    github:
      githubData:
        organization: my-org
        catalogPath: '/catalog-info.yaml'
        filters:
          branch: main
          repository: '.*'

I am not registering locations manually, they are all auto discovered. I noticed that even when I try to unregister a valid component, i.e. one having a Location entity in backstage catalog and is backed by a catalog-info.yaml in a git repo in our org, that is also giving the same message

Entity Inspector for the above entity

[night lark]

The comment about locations is about lowercase-l "location"; not uppercase-L "kind: Location" 🙂

confusingly

there's a separate locations table that's used when you register URLs that point to individual files

those ALSO get mirrored as kind: Location entities by the corresponding provider, so it's a bit confusing

what the message says is basically "oh i dodn't find an entry in the locations table so i can't do that form of deletion, i can only delete in the entities tables instead"

[latent meteor]

ah, so it IS because I don't have any static locations set up

[night lark]

well static (in config) or "dynamic" (registered and unregistered by users continuously in the locations table)

[latent meteor]

"dynamic" (registered and unregistered by users continuously in the locations table)
How does this happen? From the frontend?

[night lark]

Yeah under Create, the button Register existing URL

It's also what we always let the scaffolder templates do as their last step

It may be interesting to know that Spotify never used discovery. Discovery was never a thing at all before open sourcing; that's all invented by the community and we don't leverage it

We have tens of thousands (maybe hundreds of thousands at this point? 🤔) of individual URLs registered and that's how it's always been

Since we're obviously a mature "adopter" so to speak, there's no such thing as not-yet-onboarded software. Everything is already in there. People very very rarely care about writing yaml files, they just scaffold something and it's automagically made present in the catalog, and built, and tested, and shipped to production in one click so to speak

[latent meteor]

ahh! I forgot about that, since I disabled it.

Regarding discovery, I assumed that you folks would be more into a GitOps way of doing things.
The way I am setting things up for my org is to let developers scaffold what they need and these templates would also template the necessary yaml files for auto discovery.

But well, I love the fact that Backstage doesn't really opine on the way to use it