Hello everyone! Is it possible to detect a successful update (when all replicas in specific k8s deployment get successfully replaced during a rolling update) and then run some code/command? I'd like to use this kind of mechanism to notify users that a "new version of the frontend is available" so after a successful deployment they won't get an error (in case the old frontend client is not compatible with the new API). It's important to note, that this "update is here" event should be emitted only after ALL REPLICAS are successfully updated. I wouldn't want to tell users during a rolling update that "new frontend is here" just for them to refresh and end up on the old version (not yet replaced by the rolling update). Ideally, I'd like to be able to detect and run code/emit events on: 1. When the update is about to start (ex. image was just built and seems different than the currently deployed one) - after preview. 2. When the update started. 3. When the update is successfully finished. 4. When the update did not succeed. and display these pieces of information in the user UI accordingly. --- Few ideas/approaches I came up with: 1. Pulumi automation api I'd rather avoid this approach because it complicates the deployment process (I would no longer be able to use GitHub action

pulumi/actions

for CI/CD but rather "dedicated scripts"). Not sure it's even possible to detect which parts of the stack got updated (to publish "new frontend available" notif only on the actual frontend deployment update, and not other parts of the stack update). 2. Hack with

deployment.status.apply(() => ...magic...)

Not sure how to precisely detect what exactly changed/was updated (is full rolling update done or just a few instances etc.). 3. Combination of

Deployment

&

Job

with "dependsOn" on the specific deployment. This might actually work but haven't tested yet... One thing I dislike about this approach is it would pollute k8s stack with jobs that do not really need to exist as part of k8s stack IMO. 4. Pulumi cloud webhooks This might actually work as well but haven't tested it yet. Event filtering documentation (https://www.pulumi.com/docs/pulumi-cloud/webhooks/#event-filtering) makes me think it's doable but there is no info about what kind of payloads are to be received by the webhooks (is it possible to actually figure out that the deployment "A" was just successfully updated and "B" was left untouched?).

Hey @cool-family-40769 I think webhooks should meet your needs here. https://www.pulumi.com/docs/pulumi-cloud/webhooks/#payload-examples defines the payloads

Thanks for the quick reply! https://www.pulumi.com/docs/pulumi-cloud/webhooks/#stack-update doesn't seem to contain information about what part of the stack was updated. I wouldn't want to emit a "frontend update" when some other deployment (within the same stack) was updated.

"What part of the stack" Do you mean which resources?

yes

One option would be to receive the webhook and then make a rest request to figure out which resources have changed

That would probably work... However, I'd rather avoid using webhooks because they require extra setup (custom domain, webhook call to event in specific stack logic etc...). Do you think there is some simpler way of achieving this kind of thing?

Honestly, if I had to do this I would probably use automation api and use the event stream to figure out when the frontend is updated and use that to send the notification.

I just found this https://gist.github.com/lblackstone/d2d1c29507685c0833612988945dedf3, looks interesting...

the latter. you can certainly write automation api scripts in a way that the pulumi program could still be `up`'d normally but then you wouldn't have access to that script that processes your events and sends notifications based on the event.

Too bad

pulumi/action

does not support "user-provided automation API scripts". If I decide to go the automation API script route, I'd either have to say goodbye to automatic PR functionality (pulumi deployment comments etc.) or implement it by myself 🤔

np!