Mode for running stack when either a new commit or the Stack object changed

[squaremo]

With reference to https://pulumi-community.slack.com/archives/C01F5GS6G3X/p1671178540494389: there's no way to run when either there's a new commit, or the Stack object changed -- which you might expect to be the default mode of operation.

The description of .Spec.ResyncFrequencySeconds is

ResyncFrequencySeconds when set to a non-zero value, triggers a resync of the stack at
the specified frequency even if no changes to the custom-resource are detected.
If branch tracking is enabled (branch is non-empty), commit polling will occur at this frequency.
The minimal resync frequency supported is 60 seconds.

which suggests that if you set it to zero, it'll only fetch from git, and run the stack, when the Stack object is modified. However, these lines https://github.com/pulumi/pulumi-kubernetes-operator/blob/master/pkg/controller/stack/stack_controller.go#L602 mean that if you're tracking a branch, it will always requeue the object. This is not the behaviour that the description suggests.

If you want to run every time the Stack object changes, you set ContinueResyncOnCommitMatch: true; but, this also means it'll run at every git poll, whether or not there's a new commit.

The behaviours possible should be:

Behaviour	Settings
Run every X seconds	ResyncFrequencySeconds=X, ContinueResyncOnCommitMatch=true
Run only when there's a new commit	ResyncFrequencySeconds=X, ContinueResyncOnCommitMatch=false
Run every time the Stack object changes	ResyncFrequencySeconds=0, ContinueResyncOnCommitMatch=true
Run when the Stack object changes or there's a new commit	?

[squaremo]

NB some of the other fields mention the polling period in their descriptions; worth checking that they are consistent.

[EronWright]

Good news everyone, we just release a preview of Pulumi Kubernetes Operator v2. This new release has a new design for the logic of when to "re-sync" the stack (that is, to re-run pulumi up). In the new design, any change to the stack's spec does cause a re-sync to occur, whether that be a change to the stack configuration values, the source spec (e.g. the branch name), or any other element.

Of course, it also polls for new commits at the frequency set by ResyncFrequencySeconds.

Re-sync is about re-running pulumi up periodically, even if nothing has changed, at a frequency set by ResyncFrequencySeconds. This feature exists to update dynamic cloud resources and/or stack outputs, and is enabled by ContinueResyncOnCommitMatch.

In future, I would advocate for introducing a new field for the branch polling frequency, because it seems coupled to the true "re-sync" functionality.

Please read the announcement blog post for more information: https://www.pulumi.com/blog/pulumi-kubernetes-operator-2-0/

Would love to hear your feedback! Feel free to engage with us on the #kubernetes channel of the Pulumi Slack workspace. cc @squaremo @canthefason