Consider adding support for `diff` and `read`

[lukehoban]

These operations are supported in the Resource model, and could be delegated to commands to run on each operation. The use cases for these are not quite as rich as create and delete, but could open up additional new use cases.

[lukehoban]

The curl example in #27 is an example that could in principle benefit from this. The color and description of a label can be updated without destroying and recreating the label, but there is no way to represent this today with the API. The only thing we can implement is that any chance requires replacing the label with a new one.

[elivaknink]

a use case where we need to use a command on update:
when we increase an EBS volume we want to extend the corresponding filesystem on the instance and we need to run some ssh command to do so - see this aws article - https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html

in this case, the change is considered as update in Pulumi, so if the command module would support update we can implement it by using it.

[ghostsquad]

I think the way that go-task does this would work. The provide status field, that lets you specify any arbitrary commands to run in order to determine if a "task" should be rerun or not.

https://taskfile.dev/#/usage?id=using-programmatic-checks-to-indicate-a-task-is-up-to-date

The indicator isn't a diff, but rather just the exit code of the status commands that are run (if any of them exit with code 1, then the task is out-of-date and needs to rerun).

The Command provider could serialize state, and provide it to either stdin or as an argument to an diff command, which would be able to report whether or not the "resource" would needs to be updated or "recreated".

[jonthomp]

I would like to see this for sending updates to configure external services via API or similar

[segator]

we defintelly need update and ideally diff.
I thinking to switch all my company TF projects to pulumi but this is a big stopper for me, also no support for dynamic provider in GO :(

[joeduffy]

Another thing worth considering: recreateOnUpdate: true.

For idempotent commands, it would be really nice to trigger re-running the create when an update occurs. I've found myself wanting this many times during active development. Otherwise, you need to delete the command, run an update, add back the new command, rerun an update. This can make the inner development cycle a bit laborious.

[ossareh]

Edit: If you find yourself here note that the docs are out of date and update exists as an option 🎉

---

This would also be helpful in the k8s w/ helm case. I'd like to do something like:

const cluster = ...;
const chart = k8s.helm.v3.Release("installation" { ... });
const rollout = new local.Command("rollout", {
    // create not needed because it's the default behavior to start pods when creating the resources in the chart
    update: "kubectl -n namespace rollout deployment installation-foo",
    environment: {
        KUBECONFIG: cluster.kubeconfig,
    },
}, {
    dependsOn: [chart],
});

In my actual case the types of changes I tend to be making are in permissions assigned to the service account that the deployment specifies via annotations; these sometimes cause the annotation to change value, and sometimes are purely upstream changes in my cloud provider. k8s will only automatically trigger updates to the template spec for the pods in the deployment.

[gflarity]

I was bit surprised this wasn't already supported. As a Pulumi newbie, I was hoping/thinking pulumi-command was just a convenience replacement for a dynamic resource providers. Ie, the logic might be in shell scripts, but most of the functionality is available. For my use case I'm going to need to write my own dynamic resource provider that shells out, just so I can run updates. I'll probably even just have diff indicate that an update always needs to happen just to keep it as simple as possible.