Fredrik Adelöw

Put some thoughts about dynamic enablement here just as a discussion starter where we can gather these discussions https://github.com/backstage/backstage/issues/31220

Depending on circumstances, the `**/catalog-info.yaml` approach might be the one that uses less resources. Each such read uses [the `search` method](https://github.com/backstage/backstage/blob/3dbd527367af0cff07fabf47b0443654de33cad3/packages/backend-defaults/src/entrypoints/urlReader/lib/GitlabUrlReader.ts#L238) of the URL reader which reads the relevant parts...

So you'll need * A changeset for the package so it gets shipped * Running `yarn install` and committing the lockfile change with the PR * Running the plugin locally...

I think client side is fine for now - we are just waiting to see if @Irma12 comes back with feedback / fixes

@aramissennyeydd Hey! I've made some small movement toward this, in terms of untangling the old code so that it's basically all concentrated in e.g. [postgres.ts](https://github.com/backstage/backstage/blob/c42c2bae633f69d824f36fd76a3c81b620b933f8/packages/backend-defaults/src/entrypoints/database/connectors/postgres.ts). What I thought remains to...

`subscribe` is very simple - it calls a callback whenever that config node or any of its children have a change of data. So you'd basically do (very pseudocode) ```ts...

Remember to add a changeset and to update the test.

You could achieve this by [changing your profile transform](https://backstage.io/docs/auth/identity-resolver/#profile-transforms) of your auth provider setup so that the correct image is present upfront.

Hi! Remember `yarn build:api-reports` if they change

seems to need a rebase now too after the other PR got merged