This message was deleted.

I wonder if @Laszlo Fogas has an opinion here? He works on Gimlet which is all about a UI that commits to Git 👀 (blog to read until Laszlo can jump in! https://gimlet.io/blog/clickops-over-gitops)

@ahn heesuk: I believe this is dependent on the identity provider (IDP) you are using. In my previous experience with Backstage, after a user enters details within the software catalog, there is no direct way to identify which user has created a specific request. However, Backstage does offer a custom action feature that can be utilized to capture these values in a database or through a third-party integration. On the other hand, if we consider Port, it has an inherent feature of audit logs that is available and captures every operation performed within the system.

Hi Henry,

“Request” and “Resources” t

Requests could be pull requests perhaps? The IDP can list resources in pull requests that devs want to create. And when they are merged, they go on the cluster immediately. Or your question is more about the time when the resource is merged to main, and not yet on the cluster?

@Laszlo Fogas Thanks you for reply. It seems like a good idea to fetch pull request information and display it as a list. However, in most cases, after retrieving the list information, we click on a list item to query detailed information. To perform the query, we need to have the ID of the generated resource to fetch the information. In most application services, RDBMS is used, allowing us to query the database to retrieve information. In the context of provisioning resources in Kubernetes, my assumption is that we can query the Kubernetes API server using the metadata.label information (custom resource query for the detail view). For this to be possible, should the Commit SHA ID of the pull request match the metadata.label of the resource?

I do propagate my git hashes as kubernetes annotations, so I can match things up in the ui, yes