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

Another quick feedback. If multiple (more than one) deployments are queued, then all queued deployments except the last one should be skipped. Since a later commit on a branch does include the changes of an earlier commit. As far as I can tell, currently no deployments are skipped.

<@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>