Support Forums

Issues with build.ignore command not ignoring as required

Hi, @gray. I don’t have a good “one line” solution.

This might be done programmatically. For example, you can get the first commit in the branch like so:

first_branch_commit="$(git log master..HEAD --pretty=oneline | tail -n 1 | awk '{print $1}')"

Then that can be use to diff from that point to now:

git diff --quiet "${first_branch_commit}" HEAD \
  .netlify-dummy-dir/* \
  .storybook/* \
  app/javascript/* \
  babel.config.json \
  config/webpack/* \
  netlify.toml \
  tsconfig.json \
  yarn.lock \

Again, this will alway check from the first commit in the branch until now. If you are looking to check from the last build at Netlify, this information isn’t stored in the git repo so some other solution would be needed.

If there are other questions about this, please let us know.

Thanks, Luke! I’ll play around a little bit more. Unfortunately I don’t think comparing to master is going to help because that could potentially be super behind.

I guess I’m a little confused with the documentation, though? It seems like comparing HEAD^ HEAD would be useless unless your branches always only ever contained a single commit.

For now I’ve updated the script to be:

last_merge="$(git log --pretty=format:"%H" --merges -n 1)"
echo "Comparing most recent merge commit ($last_merge) with HEAD..."

git diff --quiet $last_merge HEAD \
  .netlify-dummy-dir/* \
  .storybook/* \
  app/javascript/* \
  babel.config.json \
  config/webpack/* \
  netlify.toml \
  tsconfig.json \

This doesn’t quite solve the problem because not all developers on the team use the merge button in Github that results in a merge commit but this gets us most of the way there.

In its current state this feature doesn’t provide as much value to us as we were hoping. If we can’t confidently run a git diff to check the changes that the particular pull request is introducing then we’re always going to get either false negatives or false positives depending on how we implement the diff.

I’d love to see this improved!

Hi, @gray. I do think the pieces exist for a high confidence solution but there is no pre-existing tooling to do so.

The workflow would require using our API manually at the moment and I agree it would be great if we had some prior art to demonstrate this.

The process I envision works something like this:

  • the script would first call our API to confirm the published deploy id for all branches with an API call to :

  • then the deploy id for this branch’s current deploy would be checked to get the Git commit reference SHA-1 value


This assumes that checking for changes between the commit for currently deployed branch and the commit being used for the build is the requirement.

I’ve tested the API and confirmed this can all be done.

If that would meet your requirement, I’d be happy to enter this as a feature request that there be a way to do that without writing the code yourself.

I’d also be happy to answer questions if you wanted to write custom code to query the API to do this in the meantime.

If you want me to enter this as a feature request, please confirm and I’ll do so. Likewise if there are any API question, please reply anytime.

EDIT: I also edited the title of this topic. I wanted to point it out for transparency and I hope you don’t mind. I’m trying to make the topic subject clear.

Thanks Luke! I’ll play around with that and see how it looks. Something else I’m considering is seeing if I can manually add a remote so that I can git fetch origin master. The ENV should have the appropriate credentials to be able to talk to Github but I’ll report back with my findings.

Regarding a proper feature request I think this would be something that most people would assume the platform is capable of due to the documentation referring to ignoring via Git but I’m a little surprised if I’m the first one to hit this issue!

(no worries about updating the title :slight_smile:)

I can tell you already, and sorry to be late with this info, but…

You won’t have ANY git permissions you don’t bring yourself; we drop all permissions BEFORE running any of your code.

You might find this article helpful in coming up with a workflow that works for you:

Hi, @gray. I cannot believe I missed this from the environment variable documentation about Git metadata:

  • COMMIT_REF : Reference ID (also known as ‘SHA’ or ‘hash’) of the commit we’re building.
  • CACHED_COMMIT_REF : Reference ID (also known as ‘SHA’ or ‘hash’) of the last commit that we built before the current build.

There is an environment variable of the previous build’s commit SHA-1 ref. With this environment variable, I don’t think any API calls are needed. Does this meet the requirements for the build.ignore command?

git diff --quiet "${CACHED_COMMIT_REF}" "${COMMIT_REF}" \
  .netlify-dummy-dir/* \
  .storybook/* \
  app/javascript/* \
  babel.config.json \
  config/webpack/* \
  netlify.toml \
  tsconfig.json \
  yarn.lock \

Oooooo nice one @luke! I’ll give that a try. I think for our first build it might be a little out of date since we’re in a weird place in our build right now but this might work once we get it merged! I’ll give it a go and report back.

I think this is going to work for us!

1 Like

I’ve added a todo item to write a support guide which covers this topic all in one place as well. :+1:


Did this end up working for you? I am trying to do something similar, and replicated what you tried in our repo, and nothing seems to be different, i.e. site is built on every change in the repo.

Hi, @ChrisChinchilla. Would you please send us a deploy id for a deploy which didn’t handle the build.ingore command as expected?

Our support team will be happy to take a look to see if we can find a solution.

Sure 5fc519553a1e4e00085592ac, it’s not that it doesn’t work, but I find the current docs hard to interpret to make it work. Basically, I only want to build on changes to the site folder.

hey chris, while luke works on that, can you tell me a little more about what is confusing? if we can, i’d like to make the docs more clear.

@perry I just posted a similar ticket related to this, can you help me out

Hey Perry, well mostly that it doesn’t say very much…

I tried running that example (changing a directory appropriately) and there’s no exit code at all, in fact, no message whatsoever. I appreciate it’s mostly a git command, but might be useful to add some more context around that. What should I expect? What does --quiet do? What is that ^ chevron character?

The OP in this thread mentions adding an external file, nothing in this section mentions that as possible… Just small things like that. It’s a rather silent config option, and you’re left a bit unclear on how to know if it’s working, and what might be wrong.

I found that this git diff --quiet site would return the correct output 1 for changes in the specified directory, but Netlify still builds the site every time anyway, so now I am even more confused as to what is going on :confused:

Hi, @ChrisChinchilla. The repository for the deploy id you shared above is public. This means I was able to do some testing using the actual repo.

I’m seeing one issue right away.

The build.ignore command is run within the base directory. The base directory for this site is site. However, your build.ignore command is site/netlify-ignore.sh. This file doesn’t exist (because now you are looking for site/site/netlify-ignore.sh. Running this build command will always cause an error because it doesn’t exist at that location.

Errors are what trigger builds so this build command will always trigger a build. Step one will be to change the build ignore to this:

  ignore = "./netlify-ignore.sh"

Note, that is “./netlify-ignore.sh” and not just plain “netlify-ignore.sh”. The prefixed ./ is very important and be sure to include that.

I also see a second issue. When I cloned the the repo and checked out the commit SHA for that build, the file permissions for that script are this:

-rw-rw-r--  1 username username   73 Dec 10 10:15 netlify-ignore.sh

This script doesn’t have the executable permission bit set so, even if you use the correct path, it still returns an error:

$ ./netlify-ignore.sh
-bash: ./netlify-ignore.sh: Permission denied

You can check the exit code with echo $? like so:

$ ./netlify-ignore.sh ; echo $?
-bash: ./netlify-ignore.sh: Permission denied

To summarize, the build.ignore command always errors and therefore it will always build.

About this:

There definitely is an exit code. Exit codes are never printed to the terminal. You need to check them using some method to see the exit code, like adding the echo $? after the command:

git diff --quiet HEAD^ HEAD sub_dir/ ; echo $?

About the --quiet option and the HEAD^, that isn’t Netlify specific. This is about Git and the answers are in the Git documentation, not our documentation.

You can use git diff help to get more information about the --quiet option. If you want to learn more about what HEAD^ means, this StackOverflow post is a good place to start:

Note, much of what you are asking about (like what the --quiet option does or what HEAD^ is used for) are questions about Git itself. These are not questions about Netlify.

I do agree having a support guide to cover this would be a great idea but putting non-Netlify specific information in our public documentation website is, in most cases, an anti-pattern (and, therefore, something we try to avoid). In other words, we don’t have extensive documentation on Git itself because Git isn’t our software and we assume a certain understanding of that software.

This type of documentation (meaning documentation about non-Netlify software or services) is more commonly done using blog posts or support guides on the community site. Again, I do think a support guide to go into more detail about the build.ignore command would be helpful. However, I don’t think putting that information on our public docs site would be the right place for that information.

Writing that is on my todo list but there are many other competing priorities for my time and this support guide is not complete yet.

1 Like

Thanks Luke! As a tech writer of over 6 years I may have to disagree with some of your points above, but that’s more opinion. :wink:

Thanks for the pointers, I fixed all of those, by try as I might, I still cannot get any combination of the git diff examples you show, or from the comments from @grey to work as intended/expected/hoped… i.e. only build when there’s changes in the site folder.

As much as I really want to get this working so we stop building docs every time the devs push code changes so we stop maxing our build minutes every month, I think I need to move on to other tasks and maybe try again with this another time :sweat_smile:.

Thanks again for your help, and maybe someone else will chip in on this thread with how they got something similar to work.

1 Like

Hi, @ChrisChinchilla. It is no trouble for us to take another look at this. If we can be of further assistance, please let us know the deploy id where the build.ignore didn’t work and we will be happy to troubleshoot further.