Revision-date updates all files.

[lyz-code]

Hi, first of all, thanks for your plugin.

I'm deploying my wiki with this github workflow. And if I change one file of the whole repository, the date get's changed in all the files.

So for example, this commit triggered this job which produced this gh-pages commit.

As you can see, the timestamp is modified in all files:

- Last update: <span class=timeago datetime=1581529194000 locale=en></span>
+ Last update: <span class=timeago datetime=1581529388000 locale=en></span>

Do you know why is this happening?

Thanks

[timvink]

Hi @lyz-code,

Good to hear you're happy with the plugin!

Trying to understand if something is going wrong or not. What this plugin does, is on mkdocs build lookup for each markdown file the datetime of the last commit that touched it. So on each deploy, all files are rechecked.

So I checked if there are any pages with incorrect timeago stamps. Let's take one file as an example: devops/aws/iam/iam_commands/index.html went:

• from Wednesday, February 12, 2020 5:39:54 PM GMT (1581529194000)
• to Wednesday, February 12, 2020 5:43:08 PM GMT(1581529388000)

The last commit on iam_commands.md was earlier, on 12 Feb 2020 10:36 GMT.

After some more searching, I realised that the date is actually the timestamp when the deploy script ran. This is likely because of these lines in the plugin:

unix_timestamp = self.g.log(path, n=1, date='short', format='%at')        

if not unix_timestamp:
     unix_timestamp = datetime.now().timestamp() 
     print('WARNING - %s has no git logs, using current timestamp' % path)

Basically, the git repository cannot be properly accessed, and the current datetime is taken. The logs should show a lot of warnings. Unfortunately, I cannot view the logs of your build ('We are currently unable to download the log. Please try again later.').

Probably, the root cause is that the github action actions/checkout@v2 by default only checks out a single commit, for speed reasons (see docs). I suggest to update your workflow and increase the fetch-depth, because you need all the commits on all the files:

steps:
    - uses: actions/checkout@v2
       with:
           # Number of commits to fetch. 0 indicates all history.
           # Default: 1
           fetch-depth: 0

Let me know if that solves it. I will make sure to update the docs and the warning message accordingly to help future users.

[lyz-code]

It worked perfectly.

Thank you for the quick and throughout analysis ^^

[timvink]

I tried writing a unit test for this. I had assumed the shallow git fetch-depth of 1 would have caused this line to return a None:

unix_timestamp = self.g.log(path, n=1, date='short', format='%at')        

and thus print these warnings:

if not unix_timestamp:
     unix_timestamp = datetime.now().timestamp() 
     print('WARNING - %s has no git logs, using current timestamp' % path)

I looked at the logs of your build job, and there's no warnings. I couldn't reproduce this locally.
Instead, the git date returned can just be plain wrong, containing the last commit date.

I've already updated the README.md with instructions when building docs with CI, but I'd like to raise appropriate warnings as well.

But determining the GIT_DEPTH is not trivial, as described in this SO post. In the end I reverted to printing some warnings for shallow clones on CI.