Adds a migration that populates a new `location_entity_ref` column on the
`locations` table with the full entity ref of the corresponding
`kind: Location` entity (e.g. `location:default/generated-<sha1hex>`).
Postgres uses an unnest-based batch UPDATE; other engines use a
transaction-wrapped per-row loop.
All code paths in DefaultLocationStore that previously recomputed the hash
from type+target now read `location_entity_ref` directly from the DB row
instead. New rows written by `createLocation` and `#createLocationsByExactUrl`
have the column populated at insert time.
This is step 1 of migrating Location entity names to be based on the stable
row UUID rather than a hash of the mutable target URL.
Signed-off-by: Fredrik Adelöw <freben@spotify.com>
Made-with: Cursor
Signed-off-by: Fredrik Adelöw <freben@spotify.com>
Made-with: Cursor
Signed-off-by: Fredrik Adelöw <freben@spotify.com>
Made-with: Cursor
Signed-off-by: Fredrik Adelöw <freben@spotify.com>
Made-with: Cursor
Signed-off-by: Fredrik Adelöw <freben@spotify.com>
Made-with: Cursor
Signed-off-by: Fredrik Adelöw <freben@spotify.com>
Made-with: Cursor
Signed-off-by: Fredrik Adelöw <freben@spotify.com>
Made-with: Cursor
Backstage is a single-page application composed of a set of plugins. This folder holds numerous plugins that are managed by this repository. However, most plugins are in the community plugins repo - hop over there if you want to contribute!
For more information about the plugin ecosystem, see the documentation here:
You can also see the Plugin Marketplace for other open source plugins you can add to your Backstage instance.
Suggesting a plugin
If you start developing a plugin that you aim to release as open source, we suggest that you create a new Issue on the community plugins repo. This helps the community know what plugins are in development.
You can also use this process if you have an idea for a good plugin but you hope that someone else will pick up the work.
Fredrik Adelöw
d16311f310