Monorepo: some builds are cancelled but not reliably

I have a monorepo with 2 folders: /back and /front
The front is a Gatsby static website.

I’ve setup 2 different creates sites, with correct /front root folder for both (because I need to deploy the same app with 2 distinct build settings / env variables). (Actually both sites existed monorepo support, but we “relinked them” as the doc said to do.

What I expect is that:

  • all commits in /back do not trigger a /front build
  • all commits in /front do trigger a /front build

What I see in practice:

  • all commits in /front do trigger a /front build
  • some commits in /back sometimes trigger a front build, which is unexpected

I’ve noticed that just after a /front commit (leading to an expected build), the 1st /back commit does often trigger a build, and subsequent /back commits are appropriately cancelled.

Also, something weird just happened. As my 2 sites are actually configured the same (/front root folder), I would expect them to behave the same. But instead of that, I just commited in /back, and site1 did trigger a /front build, while site2 didn’t! So the same configuration, with the same github repo, and the same git commit, did actually trigger different results.

Unfortunatly I can’t publish my team name publicly but if that helps you can ask me in private for more infos.

Maybe that link helps if the id is unique across all teams, it’s the build that triggered on site1, while site2 did cancel: https://app.netlify.com/teams/<HIDDEN_TEAM_NAME>/builds/5df284c0d00af00007e901f8

If that helps to reproduce, we are also using https://github.com/axe312ger/gatsby-plugin-netlify-cache

Hi @slorber,

I checked your deploy and it doesn’t look like you have a netlify.toml file that defines what builds get ignored. Did you implement the ‘ignore’ configuration?

Hi @Dennis

My monorepo will in the end contain multiple static apps, all deployed to netlify, using different netlify configurations.

As far as I understand, netlify.toml is unique per monorepo right? or can it be nested in a specific static app subfolder?

If you would like to override the default check with a custom workflow you can use the ignore attribute in netlify.toml

I don’t actually, I’m fine with default behavior, that’s why I’m not using netlify.toml.
Reading the doc let me think this should work even if there is no netlify.toml, isn’t it?
And anyway, it seems to work “sometimes” already?

Can you clarify what’s the default behavior exactly when there is no netlify.toml? because what the doc says and what I see in practice does not seem in sync.

Can you clarify what setup should I do if I have:

  • /backend
  • /staticSite1
  • /staticSite2
    (where should I put which netlify.toml file)

If I commit to staticSite1, it should not build staticSite2 nor backend

@slorber, you can have separate netlify.toml in each of your base directories with our monorepo support. On the site you need to make sure you’re using the xenial build image and make sure the repo was linked after October 3rd (re-link it if you initially linked before then).

If you don’t have a netlify.toml at all and you set a base directory and build command in the UI then we’ll just run that build command from the base directory.

If you want a site to ignore builds from other directories then you’ll have to add a netlify.toml with an ignore directive as it’s described in our docs: https://docs.netlify.com/configure-builds/file-based-configuration/#ignore-builds

Hi @futuregerald
Thanks for telling me I can have multiple toml files, didn’t know it was possible.


If you want a site to ignore builds from other directories then you’ll have to add a netlify.toml with an ignore directive as it’s described in our docs

I’m re-reading the doc again and again:

For sites connected to a Git repo after October 3rd, 2019, Netlify tries to determine if there are any changes in the site’s base directory by comparing the last known version of the files within that directory. If no change was detected, the build system skips the build, returning early from the build process.

If you would like to override the default check with a custom workflow you can use the ignore attribute in netlify.toml which allows you to specify a unix shell command that will be run from the base directory to determine whether you consider the site to need rebuilding or not.

  • My site is connected after the 3rd October.
  • My base directory is ./staticApp
  • I am fine with default behavior mentioned, which says that I don’t need a toml file to ignore files committed outside my base directory

I still think that whether the doc, or you, is wrong, because both don’t say the same thing as far as I understand it.

To me the doc says that if I have an app connected after the 3rd, without toml, and with ./staticApp as base directory, committing files to ./backend will not trigger the build, because the default behavior (in case of absence of netlify.toml file or ignore directive) does exactly that. I don’t necessarily want to override that default behavior, so I don’t necessarily need a toml (according to the doc).

Note that this default behavior seems to almost work for me, only some builds are triggered but most are filtered, so my opinion is that @futuregerald you are wrong and the doc is right but there is a potential bug on your default behavior that prevents it from working in all cases.

Still, will try with a toml to see if it works better after.

Hi,

That’s certainly possible, can you try adding the ignore directive and let us know if your builds are skipped more reliably in this case?

Related question here – it looks like the ignore build command, if provided in a netlify.toml file, runs “from” the base directory when one is specified, is that correct?

This appears to be true both when the netlify.toml file is in the site root, and also when it’s in the configured base dir (ie, no matter where the netlify.toml file is in a monorepo, the ignore command will run from the base dir when present).

If so, that might be a useful improvement to the docs around how the ignore config works. It was clear to me how the exit statuses would matter, but not clear to me where the command would run from.

good point, @mjankowski. We’ll take a closer look and if applicable, update the docs.