Patrik Oldsberg

👀, core maintainers will do another pass on this in the coming weeks to make sure we're all settled on the design

The issue seems to be a mismatch between the HEAD sha of the ref at https://github.com/backstage/community-plugins/blob/1ac989eeb33f69578a9f55e5568bd3496cc25575/.github/workflows/release_workspace.yml#L54 and the sha that the `backstage/changesets-action` action ends up using. For example, in the...

@schultzp2020 this is one that could use some exploration if you're up for it

Do you have the setup mentioned over in #23762 with this? ```ts backend.add(import('@backstage/plugin-catalog-backend-module-gitlab/alpha')); backend.add(legacyPlugin('catalog-gitlab', import('./plugins/catalog'))); ``` For each plugin you'll need to either fully use the new backend system wiring...

Hmm, hard to say exactly what might be wrong from that information. It could help to try to step through the auth flow manually to see where and how it...

@jhaals Thanks! > Is there a cutoff in the event history or is that table expected to grow forever? If the offset is an ever growing integer I would be...

@freben Thanks! > So I guess that then begs the question - is this proposal intentionally limited to only create/update/delete of entities and that may forever be the end of...

@Xantier Thanks! I think feeding events into either a replicated log or event stream system are both things that make sense, just wanna consider carefully whether we'd start in that...

@msamad I think this would initially only be for the catalog, as we'd be striving for correctness across the entities and events endpoints. That doesn't mean we can't explore the...

@msamad indeed :grin: What are you thinking that would look like, do you have a specific use-case in mind?