Disable Deploy Cancellation on New Deploys

With auto-deploy on, when a new commit appears, it cancels the existing deploy and instead starts on the deploy for the new commit:

Deploy canceled for 6fb0c22: Update dependency ...
Another deploy started
September 5, 2024 at 7:23 PM

Deploy started for 962b052: Ignore fixture files
New commit via Auto-Deploy
September 5, 2024 at 7:23 PM

Deploy started for 6fb0c22: Update dependency ...
New commit via Auto-Deploy
September 5, 2024 at 7:20 PM

Would it be possible to get an option to disable this (or queue the outstanding deploys instead of immediately cancelling the in-progress deploy)?

Prior Art

  1. Netlify does this with their deploys

There are many possible resolutions to this situation:

  1. If you need every deployment to finish for some incremental data reason, you should build that logic into your app itself. See database migrations for example; it runs all that need to run, in the order they need to be run, whenever the migration mechanism is invoked.
  2. Commit more, push to main less. Push main only when an atomic “delivery” is ready. Branch-based workflows work well here.
  3. Turn off auto-deploy and deploy only when you want.

Ok, so the Render team rejects the request for a Render.com feature to enable the sequential deploys for a project / account? (to match the feature Netlify offers)

Changing our app or adding additional workflow steps are less helpful than a set-and-forget option would be.

Render is not Netlify. Render is not related to, nor built on the same platform as Netlify. We cannot simply “enable the Netlify sequential deploys”. You can (search for, and if not already posted) request features via https://feedback.render.com/

It was probably a bit compactly-worded, I have re-worded above

Since it appears this community forum is not the correct place to ask for features (too bad, would love to have support + feature requests in one place), I have searched on the other external platform, and it appears there are already feature requests marked “Planned” for this:

I’ll keep an eye on those.

To respond to your clarification;

Neither I, nor the Support Team, are rejecting the idea. Generally we are not the arbiters of feature requests. We can comment and participate in development work, we can champion and ask for things we care about, but to a certain extent Product Management and Executives are the ones to make final determinations. No, I am not making a statement on the existence of a feature beyond that it doesn’t exist right now.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.