No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

I've got a feature I'm working on to automatically create a scheduled pipeline in Gitlab with each new EKS cluster created via Pulumi.

Since the gitlab provider in Pulumi doesn't yet exist, and support in terraform for scheduled pipelines is still in MR (<https://github.com/terraform-providers/terraform-provider-gitlab/pull/116>) I'm trying to find another way to tie in the pipeline creation.

Short of writing my own Pulumi provider for the purpose, the gitlab REST API works great for this, so I thought perhaps there's a way in pulumi to:
- during `update` check if a scheduled pipeline already exists via the gitlab API, and if it doesn't then create one
- during `destroy` check if a scheduled pipeline already exists via the gitlab API, and if it does then delete it

Is this reasonable? Is there a better approach for doing this?

I think that it depends on the ability to determine in code if pulumi is doing an `update` or a `destroy`

I think you can use a dynamic resource provider for this.

<https://pulumi.io/reference/programming-model/#dynamicproviders>

&gt; Short of writing my own Pulumi provider for the purpose, the gitlab REST API works great for this, so I thought perhaps there’s a way in pulumi to:
&gt; - during `update` check if a scheduled pipeline already exists via the gitlab API, and if it doesn’t then create one
&gt; - during `destroy` check if a scheduled pipeline already exists via the gitlab API, and if it does then delete it

Do note, though, with a dynamic provider, it itself is bound by the rules of a resource lifecycle like any other resource. That means, its destroy/create/update functions are only called if the `diff` function indicates to the engine that there are changes and a replacement or a delete/create has to occur.

You could pass as inputs another resource’s properties, which could help your `diff` function determine the correct action based on whether or not something changed in the dependent properties, i.e. trigger a delete/create when appropriate.