Trigger build on changes that happens on a folder different than the base folder

Hello, I’ll first describe the project and repo structure and then our specific problem:

github repo/

This appears to be a monorepo but it isn’t. The root package.json file is not related in no way to the app/package.json file. We have Netlify connected to that repository and the app we are deploying is under /app, so in the netlify.toml file we have the base folder option set to app. Everything works great.

The problem came up when in our app build we needed to parse files located under /docs. Since the base folder is set to /app, when there are changes on any markdown document located under /docs, Netlify’s build is canceled due to no changes detected. I thought about changing the base folder to point to the root folder, but that will make Netlify pick the root package.json and that’s not what we want. We can’t at this point do structure changes to that repo as we don’t own it and there are other tools that depend on this structure.



Hmm, as far as optimal solutions, you may be stuck unless the team who does own the repo is willing to make changes for you. They could change netlify.toml in the base/ subdirectory to include a custom ignore script, which would be ideal. Here’s the docs for that setup:

If that isn’t possible, you could use a suboptimal workflow of:

  1. don’t set the base
  2. let us parse /package.json and do the (pointless, wrong) install
  3. your build command is “remove node_modules, cd app, npm i, run build”

Yup, pretty suboptimal. Hopefully they’ll be willing to put an ignore script in place for you that takes into account changes in docs directories (or at a minimum - just runs /bin/false - since that will cause ALL deploys to build regardless of that check).


I believe the ignore script is the most elegant solution, the only downside is that the build will run for modifications outside the app and docs folder, but that won’t be a big issue at this point.

1 Like

Well, you can make the script do anything you want - it could do checks like we do, only tailored to your needs :). You’d want to write and troubleshoot that script in our build environment on a separate site most likely, since I imagine that getting any changes in place is non-trivial

/bin/false will just turn that feature off which is easier but might cost you some money in build minutes.

1 Like