Slack hook only have option for failed deploy but not cancel

Hi,
we recently move to Monorepo and start using Netlify Base directory
one of the futures of the Base directory is that if the Base directory doesn’t have changes it will cancel the deploy.
we using slack notification but now every time deploy cancel we get failed notification
there is way to change this behvier or its still in the works

thanks
yotav

2 Likes

Hey @yotav_masa,
Unfortunately, there’s no way to change that behavior since we only have hooks for these deploy states:

  • request pending
  • request accepted
  • request rejected
  • started
  • succeeded
  • failed
  • locked
  • unlocked

But I’ve filed a feature request and we will update you here if there’s movement on it!

1 Like

We would love this feature too - thank you!

2 Likes

Added your vote to the issue!

2 Likes

Thanks so much, Jen!

Making the webhook triggers higher resolution would go a long way in helping use the recommended workflows and take full advantage of all of Netlify’s native features. Rather than ejecting and using custom integrations to fit our use case.

In case it’s useful to the team, here are some triggers that we would love. And below I’ll describe our use case and solutions (which seem quite common based on other forum threads I’ve read).

Webhook Triggers

“Deploy cancelled” or “Deploy ignored”
As described above. Usually happens when the “no content change” step happens. Or when an ignore flag passes. Maybe this webhook response includes the reason in the body.

“Deploy continued”
The opposite of cancelled. The build and deploy decided to continue.

Use case

We have a monorepo with ~6 different sites (and growing!). And we use Slack notifications heavily to monitor our systems.

If we make a change to one site, then we get bombarded with “Build Started” and then seconds later “Build Failed” for all the repos with no change.

We are currently solving this by:

  • Using GitHub Actions and the path: site/** directive
  • Disabling automatic git deploys using this strategy you mentioned
  • Triggering all deploys via Build Hooks
  • Finally, we are using some middleware (Zapier) to filter out webhook triggers that don’t need to be notified (e.g. Cancelled Builds)

So, if Netlify adds the webhooks above, then we would be able to skip all of these steps. And instead we would use the normal Netlify deploy process and listen for webhooks:

  • Continued (instead of Started)
  • Failed (which does not include Cancelled)
  • Successful

Thanks again for all the support and the super clear answers on the other threads. We’re very happy new Netlify users!

1 Like

hey there, @overstory :wave:

Thank you so much for the excellent details as well as the kind words you shared there. I will be sure to pass them on as well.

The current behavior is a UX bug – if the only ticket filed for this is a “feature request”, I suggest that it be reclassified as a bug and triaged as such, or else have a separate bug ticket filed which addresses just this narrow concern.

While having more granular notification options might be useful for some people, I’d be content with having no way to get a notification when a deploy is canceled due to the base directory config. From the user perspective, this isn’t a failed deploy or a successful deploy, and so doesn’t match any of the hooks currently available. (And I think triggering an inappropriate hook is a bug.)

Currently, my only 2 options are to remove the base directory setting (triggering successful deploys when they are not necessary), or continue to receive deploy failure notifications from Netlify every time I push code changes unrelated to the Netlify deploy. That’s not a choice I feel good about having to make.

Hi @zacronos, could you please explain what exactly you mean here. Dos your base directory change every build?

It would help us add details to the feature request or decide if it’s a bug according to your use case.

Sure. The short version is that it is impossible to use the base directory config for its intended purpose (cutting down on unnecessary deploys) without also triggering spurious deploy failure notifications.

My scenario: I have a monorepo, which contains code for 2 different deploys. So, in my Netlify config, I set a base directory, as recommended by Monorepos | Netlify Docs. According to that page, this “ensures a more efficient build”, and prevents Netlify from “triggering unwanted builds from changes elsewhere in your project repository”. When I merge a set of changes which only contains files outside that directory, Netlify does not need to do a deploy, so I am using the base directory config in the recommended way, for its intended purpose.

I also have a notification set up to “Message Slack when deploy fails”, which is a good way to stay informed of problems.

When those 2 things are combined, the current behavior is that Netlify starts a deploy, does a diff and realizes nothing has changed within the base directory, and cancels the deploy. That part is fine – but then it triggers a “deploy fail” notification, even though (from the user perspective) there was no failure, and nothing is wrong. Merging changes I’ve told Netlify are not relevant to the deploy should NOT trigger an alarm-inducing deploy fail notification. This leads to the dev team learning to ignore deploy failure notifications, because they frequently happen when nothing is wrong, which largely defeats the purpose of having deploy failure notifications in the first place.

Hi @zacronos,

Thank you very much for the detailed explanation.

The problem is that, the backend stores deploys in building, failed, or successful state only. So, if it’s not building, it’s either successful or failed. This is why the notifications trigger for cancelled builds too, as the cancelled builds are stored as “failed” in the database.

That’s no reason to justify this behaviour, but I just thought an explanation could help. I’d pass this on to the devs with your feedback.