HI all! I have a dilemma these days. It’s about integrating IDP development with GitOps. In the GitOps world, Kubernetes CRs (Custom Resources) are committed and merged into Git to maintain a single source of truth, and then deployed to the cluster using tools like ArgoCD. While Git is familiar, integrating it into an IDP GUI (Graphical User Interface) can lead to complex issues. Let’s consider a scenario where a specific application needs to be created in the IDP. In this case, the user enters the required parameters in the IDP GUI and initiates the creation process. However, this process should first result in a Git commit, followed by successful deployment. The problem is that the IDP cannot display the “LIST” screen until the deployment is carried out via Git events. So, until the deployment happens, the corresponding “LIST ITEM” cannot be retrieved. In my opinion, to resolve this issue, it might be necessary to separate the “Request” and “Resources” tabs. The “Request” tab could store the necessary parameters in a DB table, and the provisioning of the created “Resources” could be tracked independently. Do you happen to know any successful projects that have resolved the integration between IDP and GitOps? Thank you for reading this lengthy message.

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