When using a GitHub Action (GHA) to publish my site, I know (thanks to an old thread on this Discourse) to specify fetch-depth: 0 in the branch checkout so that my use of .GitInfo will produce the desired result: mainly, page-specific .Lastmod and GitInfo.Hash data. However, if I use a host’s native GUI instead of a GHA, this data is from the site’s most recent commit, rather than the page’s. Since I’m using a partial to get this data for the page, that means every page using the partial is showing that data.
I have seen this behavior in tests of the GUIs for Cloudflare Pages, Netlify, and Vercel — and, to my knowledge, other Hugo sites publish via their hosts’ GUIs yet seem to get per-page .GitInfo data. Also, neither the documentation nor my search for more info, much less my examination of other Hugo sites’ repos when those are viewable, leads me to think that those folks are doing anything special to achieve these results (which is especially odd to me given that it appears hosts are specifying fetch-depth at higher numbers, such as 2 for Vercel). Thus, I don’t know why my site must use a GHA to get truly per-page .GitInfo data.
My .GitInfo-specific code is the following partial, which provides the title sections of nearly all of my pages:
Thanks in advance for helping me understand where/how/whether I’m doing this wrongly.
Hi, Bryce. In this article, you advise not to include the script in our build command, but I’ve successfully implemented this solution proposed by @jmooring and it’s working fine on my site deployed by Netlify
@alcarazr Thanks. I’ve seen that before, but note the person’s original request to which @jmooring was replying:
Unlike the current system, I don’t want this to be specific to a certain page, I just want the latest commit in my current branch to be shown.
On the other hand, what I wanted was to display Git information that was specific to each page. Of course, quite a few folks prefer the last-commit-wherever approach that the other person requested, so that’s absolutely fine — whatever meets one’s specific needs.
The thing is that I’m using that approach to show my latest commit on the branch (see the end of this line), but also showing the latest commit of a specific page with this. See this example page. Above I have the latest specific edit and below on the footer I have the very latest commit on my site. All deployed by Netlify using this build command, using this script.
Perhaps Netlify allows deeper fetching than Vercel (fetch-depth: 10), where I spent the most time testing this — and, as I explained, I had no luck period with the Cloudflare Pages UI, so I couldn’t verify anything there. I will update my post accordingly as I learn more.
Yes, that was one of the issues I saw, and I agree.
Also, based on the comments from @alcarazr, I just tried a straight deployment to Netlify without using my alternative method and, indeed, it appears to be a complete clone or at least a very deep one; all the Git commit data straight from .GitInfo is accurate. So, apparently, I’ll need to revise my post to note that this is more of a host-agnostic approach but that not all hosts need it, depending on their individual fetch-depth settings — which i probably should’ve concluded in the first place.
Have updated my post accordingly. Also was able to determine the following through further testing:
Cloudflare Pages and Render do shallow clones, as does Vercel.
The alternative procedure I described works on those hosts, too; previously had been able to test it only on Netlify (which, as I now know, doesn’t need it because it apparently does deep clones) and Vercel.
Tried to test on DigitalOcean’s Apps Platform, as well, but that host’s GUI has gotten awfully “grabby” (throwing “plans” at you and the like) since I last tried it, so I aborted the attempt.
- uses: actions/checkout@v3
with:
submodules: true # Fetch Hugo themes (true OR recursive)
fetch-depth: 0 # Fetch all history for .GitInfo and .Lastmod
Come to think of it, both GHP and GLP obviously depend on CI/CD, so there wouldn’t have been any point in my testing either in the first place. That is, the whole point was to get the good data with the non-CI/CD build process touted by the other hosts I mentioned, since — as you showed — it’s easy to specify the fetch-depth with either.
Blobless clones seem to be the best solution for deployment, not sure why only Netlify does that . I was thinking about moving to Cloudflare Pages (starting to have bandwidth concerns with Netlify) but this is something to consider .
. I was thinking about moving to Cloudflare Pages (starting to have bandwidth concerns with Netlify) but this is something to consider 
.