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.
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.
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 ENVshould 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!
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?
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.
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
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:
To summarize, the build.ignore command always errors and therefore it will always build.
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.
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.
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 .
Thanks again for your help, and maybe someone else will chip in on this thread with how they got something similar to work.
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.