Bug: Non-Functional on Vercel; Incorrect Dates, Fatal Errors, Etc.

[joshuatz]

Related: See #5

Error from process (before my own error gets thrown):

fatal: not a git repository (or any of the parent directories): .git

Then my error is thrown (here).

Likely culprits:

• How git is exposed on Vercel (will require some research and/or signing up to test)
• Something to do with how I handle paths (Vercel likely uses symlinks for deploys...)

[joshuatz]

Finally had some time to do some digging on this and setup a test repo connected to Vercel to do some debugging. If I'm being completely honest, I'm a little frustrated by the Vercel docs; there is lots of info on Github integrations, but not very much information published on how they use Git internally as part of their build/deploy process.

fatal: not a git repository

I think this was fixed by #5 - I did not get this error with my test repo - however, technically I actually kind of should have.

Pretty much the only piece of related documentation I could find related to how Vercel uses Git for deploy builds was this discussion post: "Access git logs in build process". Things must have changed since then, since git operations, including git log, work in the per-deploy folders; however there is a huge catch to this (see below).

Using git in Vercel's Build Process

A basic test showed that git log worked inside a Vercel build step, and my tool could produce output. However, aligning with what was reported in #5, the timestamps in the output all were identical and simply had the timestamp of the latest commit. This is a huge red flag, as you tend to see this kind of behavior with systems that use some sort of shallow copying of history. As it turns out, that appears to be exactly the case.

What I Could Discover

In playing around with a test repo and trying out a bunch of git commands, I was able to find the interesting findings:

• Vercel did not preserve my branch name: main became master
• Only the last commit was ever present
  • git rev-list --count HEAD output 1
  • Running git log only ever showed the very last commit
  • Operations to HEAD~1 or further back failed
• Git showed that all files were always changed in the very last commit, even if in truth only one had (or zero)

All the above findings point to Vercel basically using a shallow copy of the git repository on every deploy. Realistically, they are probably using something like git clone --depth 1 ..., which only grabs the last commit and would produce all the above results.

I can't find this in their current source code, but it looks like they used to use --single-branch with a SHA ref, which should also act like --depth 1

Workaround

My suggested workaround for this situation is actually the same suggestion I give in general for using this tool with build systems that might or might not have full git history; run the tool locally, save the output (e.g. timestamps.json), and keep it in version control, preferably being committed automatically with a git hook. This approach has several benefits:

• Your build system does not need to have git installed, at all!
• Potential performance improvements:
  • Update stamps / scan for only files that have changed
  • Results can be cached

This is also the current approach I'm using for a large Gatsby project that turns a bunch of documentation Markdown files into a static site. I have a writeup on it here, the system is live here (see the timestamps at the bottom of every page on the site), and there is also a related docs section for this tool here.

The one downside to this approach is that it makes committing slightly slower for developers. It also requires setting up git hooks, but at least with something like husky, this is less intense than it used to be.

[joshuatz]

@johnleider Tagging you for the above, in case you are interested in what I discovered after looking into your issues using this tool with Vercel.

The TLDR of the above is that Vercel appears to use a shallow copy (last commit / tip) of a given git repo, which essentially makes it look like all files were created / modified in that commit. There is no (easy) workaround I know of to get the full git history exposed on Vercel, so my suggested workaround for situations like this is to simply generate the timestamps locally, as part of a commit hook, and commit the timestamps file to source control.