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

<@U032VASSQCR> thanks for this feedback! a couple questions if you don't mind, to help clarify how you might expect the product to behave.

first tell me a little about where you're most interested in seeing this -- are you primarily thinking of the push-to-deploy scenario, manual deployments triggered via the website, the API, or some combination of all of those things?

&gt; Since a later commit on a branch does include the changes of an earlier commit
i agree we can detect this case and short-circuit in-flight deployments. do you think it would be reasonable to still show these as "Canceled" in the UI?

lastly, in the cases where the branch doesn't include an earlier commit -- for example if a branch pushes commit A, rebases, and then pushes commit B -- would it be reasonable to still perform deployments for A and B?

I don't think this should be the default behavior. At least an option should be provided if that were the case.

An earlier deployment might succeed where a later one won't. It's easier to differentiate and diagnose the errors if they are deployed in the order they are committed and not skipped.

<@U032VASSQCR> would you mind opening an issue? <http://github.com/pulumi/service-requests/issues/new|github.com/pulumi/service-requests/issues/new>

I think we could offer this as a configurable setting. For the time being you can manually cancel queued deployments from the console.

<@U03MCHZARD0>
• we are currently interested in the push-to-deploy scenario, however I think having it configurable for different combinations of triggers would be great
• cancelled deployments should be still shown in the UI, GitHub Actions has an similar approach (see screenshot)
• the rebase question is tricky, but once a deployment is started is should complete, just pending once should be skipped. that should do the trick i think.
<@U049EEANUNM> Agree. Having that as an option instead the default is better

<@UQ8K13T7X> <https://github.com/pulumi/service-requests/issues/136>