Page MenuHomePhabricator

GitInfo cache behave different from Manual:$wgGitInfoCacheDirectory description
Closed, ResolvedPublic

Description

Mediawiki 1.31.1
php 7.0.33-1~dotdeb+8.1

There are two lines error log about gitinfo.json in debug output, which we can't resolve at all.

[gitinfo] Computed cacheFile=/wiki/gitinfo.json for /wiki
[gitinfo] Cache incomplete for /wiki

The https://www.mediawiki.org/wiki/Manual:$wgGitInfoCacheDirectory state that

Directory where GitInfo will look for pre-computed cache files. If false, $wgCacheDirectory/gitinfo will be used.

We got the $wgGitInfoCacheDirectory set to false as default, and $wgCacheDirectory = '/tmp/mw-cache-wikiname';.
However, the gitinfo.json were still saved to /wiki/gitinfo.json then failed, instead of /tmp/mw-cache-wikiname/gitinfo/gitinfo.json .

Moreover, the /wiki folder was set to 755 www:www. But the creation of /wiki/gitinfo.json still failed.

Is this a bug in gitinfo caching mechanism or we are not caching the gitinfo in right way?

I do found a open task T131003 talk about this problem in 2016 (3 years ago), which suggest that the gitinfo cache were not worte. Is this still ture?

Details

Related Gerrit Patches:
mediawiki/core : masterWording

Event Timeline

Zoglun created this task.Feb 10 2019, 2:07 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 10 2019, 2:07 PM

If $wgGitInfoCacheDirectory is false, then GitInfo::getCacheFilePath( $repoDir ) will return "$repoDir/gitinfo.json". I have updated the documentation that had an incorrect assumption about how this variable is used. If you are hoping to actually generate and cache gitinfo.json files you will need to explicitly set $wgGitInfoCacheDirectory to a writable location such as "$wgCacheDirectory/gitinfo".

It looks like some of the business logic in this class was broken when @Legoktm introduced rMWa5ed38dc54af: GitInfo: Allow cache to be in the extension directory itself. There are a lot of checks in the code to make sure that it does not try to write cache files when $this->cacheFile === null, but that commit ensures that state never exists.

@bd808,

Thank you for update the documentation page. I will test the $wgGitInfoCacheDirectory latter today.

In our test, $wgGitInfoCacheDirectory = "/tmp/mw-cache-gitinfo"; has no effect on the gitinfo at all. (at least for MW 1.31.1) Mediawiki still tying to generate gitinfo.json under /wiki folder.

[gitinfo] Computed cacheFile=/wiki/gitinfo.json for /wiki
[gitinfo] Cache incomplete for /wiki"

We tired to set /wiki foler with 777 permission. But no gitinfo.json generated again. (neither /tmp nor /wiki). The gitinfo cache generation function does not seems to work at all.

Seb35 added a subscriber: Seb35.Jun 1 2019, 12:13 PM

If I understand correctly your issue, it is the same as in T131003: gitinfo.json files are not generated.

It seems you assume that there is a permission issue on your side, but there is no function inside MediaWiki to write these files, so it cannot work in any case :) These files are generated by Wikimedia’s specific deployment tool (scap) or during tarballs generation.

Possibly the wording is misleading: Computed cacheFile=/wiki/gitinfo.json for /wiki does not mean that this file is written, but only that the candidate file for reading is /wiki/gitinfo.json. And if there is no such file, the next method is used (use of the binary git).

Change 513728 had a related patch set uploaded (by Seb35; owner: Seb35):
[mediawiki/core@master] Wording

https://gerrit.wikimedia.org/r/513728

Change 513728 merged by jenkins-bot:
[mediawiki/core@master] Wording

https://gerrit.wikimedia.org/r/513728

@Zoglun: can you confirm you neved had a gitinfo.json file written? If so, and with the wording changed in the merged patch, this task becomes a duplicate of T131003 (for which I proposed a new maintenance script, see the patch there).

Zoglun closed this task as Resolved.Jun 10 2019, 1:35 PM
Zoglun claimed this task.

There aren't any gitinfo.json file created under /w/ folder.
Mediawiki 1.31.2 .

I have changed this task to resloved as duplicate of T131003 . @Seb35 Thank you for the fix.