Duplicated deploys and duplicated webhooks

Hello,

I just noticed an unexpected entry in my Deploys list (site name: elegant-keller-dcc0e3):

You can see that there were 2 deployments for a single commit (hash 49256d1) even though I only pushed once, and did not do any manual triggers.

My question is: is there a guarantee that there’s only going to be 1 and only 1 automatic deployment per commit pushed to the main branch?

The reason I’m asking is because I’m writing some handlers to be called by your webhooks and I want to be sure that I am properly handling such calls (by the way, I in fact noticed these duplicated calls on my end when I received 2 calls by the webhook, and confirmed it by going into my Netlify account and looking at the dashboard).

Hey @jverce,
Yeah, there are quite a few deploys from the same hash in your deploys list. Can you talk us through your workflow for deploying? I ask because even when doing a force push, you’d see the same commit message but a new hash, so I’d like to learn more about how you’re getting so many merges with the same hash here. Thanks!

Oh, nevermind those multiple deploys / repeated hashes, I’ve been doing some testing and manually redeploying the same handful of commits over and over again.

The deployments in particular I’m concerned about are these:

As you can see, these are both for the same commit, on the same branch, and only ~0.5 seconds apart (as per the created_at values).

So my hypothesis is that Netlify guarantees that for a given commit it’ll trigger at least 1 deployment. Is that the case? Or do you guarantee 1 and only 1 deployment per commit?

Hi Jay!

We don’t provide any guarantees like that. Specifically:

  • we do TRY to start a deployment with every hook sent (which you can re-configure at GitLab differently than our default, so I won’t say “per commit” but instead “per notification received”), but if there is a bug or outage, it could fail to happen (fail to start, fail to complete, fail to be queued to start later).
  • we do NOT try to block you from double or quintuple deploys. We trust that you will configure things well and if you ask us to build twice, we build twice. If you queue up a few deploys on the same site and branch, we WILL skip the middle ones - but not the first and last, so in your case - we built the first and last.

So, how can you be sure you won’t build extra, or that you’ve built at least once? No direct feature here for that, but some suggestions:

  1. the usual reason for the duplicated deploys is misconfiguration at GitLab - you have duplicate webhooks. Mind checking the config, here to see if you have >1?
  2. you could use the ignore script to try to prevent a second build from running: https://docs.netlify.com/configure-builds/file-based-configuration/#ignore-builds

How would you accomplish #2? Kind of the swiss army knife - our API! [Support Guide] Understanding and using Netlify's API has more details, but some specific things that may help:

  1. you can (in your ignore script) query (via API) if a site is already building on a given branch, and choose to cancel the second build
  2. you can choose to use build hooks that you trigger instead of relying on your git provider: https://docs.netlify.com/configure-builds/build-hooks/

Hope that gives you enough options to come up with a solution that works for you.

Thanks! Indeed I see 2 webhooks pointing to the same URL:

I think this might have been caused because I created 2 sites for the same repository.

This raises some other questions:

  1. Suppose there was indeed some mismanagement somewhere and Gitlab webhooks ended up being in bad shape. What’s the safest way to clean up those? Does the Netlify API provide a reference to the Gitlab hook that we can use for that?
  2. If other developers create site out of the same repository and branch, there’s going to be multiple webhooks on that repository. Does Netlify make sure that the correct hook calls are redirected to their corresponding sites?

Thanks again!! :slight_smile:

Whew, that makes much sense! Both that there would be two (causing two builds) and that the reason for the two would be “configured two netlify sites to use this repo”. When you or we remove a netlify site or its repo association, we do NOT (cannot, if we do it, since we have no permissions to your git login; only your browser has them!) remove any webhooks that were configured prior, so you’ll need to clean those up yourself if you re-re-reconnect that repo :slight_smile:

Our API cannot manage hooks for you; you’d need to write your own code against GitLab’s API to automate that and we won’t be able to advise you on that. Usually I advise people to do it via their UI since I know how to do it there and it is only a couple clicks; if you need something more advanced you’ll have to build it.

Your last point doesn’t quite map to how we handle notifications from the git provider. Here’s the details you’ll need to understand how it works and plan your workflows:

  • One hook on a repo will notify ALL netlify sites connected to that repo, regardless of who configured either side.
  • the URL’s in your screenshot, “https://api.netlify.com/hooks/gitlab” are “build from a gitlab commit ONLY” and will show the above behavior. HOWEVER there are per-site buildhooks you can configure here (and manually put in place at GitLab to use instead or in addition): https://docs.netlify.com/configure-builds/build-hooks/
  • You should configure how each site builds - e.g. skip branches or PR’s, only build when you tell us rather than on every commit, don’t build at all sometimes, etc. Though it is targeted at the use case of “reduce my bill”, it is perfect for your needs today too: this article describes your options for configuration: [Support Guide] How can I optimize my Netlify build time?
  • people who do not have administrative access to your repo, at GitLab, will not be able to connect it to any site on Netlify, whether the Netlify site is in your account or in their account. So unless you are giving our administrative access to all of your other developers, they’ll need to at a minimum fork to connect it to Netlify.

Hopefully that helps you design a good workflow for your needs!

Hmmm, I’m a bit confused about a few things you mentioned:

Whew, that makes much sense! Both that there would be two (causing two builds) and that the reason for the two would be “configured two netlify sites to use this repo”

One hook on a repo will notify ALL netlify sites connected to that repo, regardless of who configured either side.

While this is true, you can still do some filtering. For instance, when creating a webhook in Gitlab you have the opportunity to provide a secret token. You can provide a unique token and associate that with the site for which the webhook was created. Whenever a webhook makes a call it provides that token in the x-gitlab-token header, which you can use to see if they match and if they don’t just disregard the call.

A cleaner but more expensive solution would be to create a unique “internal” URL for each site, and associate that to its corresponding webhook.

This would avoid multiple builds for a single commit. Each commit will rebuild every associated site just once, which is the expected behavior. Otherwise, if you have let’s say 10 sites associated to a single repository, for each commit in that repository you could potentially end up building each site 10 times!

When you or we remove a netlify site or its repo association, we do NOT (cannot, if we do it, since we have no permissions to your git login; only your browser has them!) remove any webhooks that were configured prior

This is something that doesn’t quite add up from my point of view. When connecting my Gitlab account to my Netlify account, the OAuth process kicks in and I grant Gitlab permissions to Netlify. You actually use those permissions to create these webhooks in Gitlab in the first place whenever I create/link my Netlify site to my Gitlab repo. Why not delete them when the site gets deleted?

Thanks again for all the help! :smile::heart:

The access you grant to us (for the long term) is only for reading your source code - we shouldn’t be able to change any other settings using it (intentionally). For setting up the webhook and linking the repo, your BROWSER does that stuff for you - we don’t “get” that access on our servers at any point - and that setup leaves us only with a deploy key that we can only use to pull source code (read only) from that single repo (for GitLab users anyway. GitHub users use a better system, using an app, that doesn’t need hooks). If you later link a repo, and you are signed out of GitLab when you do so, you’ll see that you have to sign back in during the linking so your browser again has permissions to do the magic :wink:

Your suggestions are good ones, but won’t be implemented very soon I think, so for time being I’d suggest manually deduplicating any webhooks on your repo(s) that we create.