Compare https://github.com/wikimedia/mediawiki/blob/1.26.0/includes/libs/objectcache/BagOStuff.php and https://doc.wikimedia.org/mediawiki-core/1.26.0/php/classBagOStuff.html.
Method makeKey() was introduced in 1.27, yet it is listed on doc.wikimedia.org on 1.26.0 as well as other <1.27 releases. It looks like the build was triggered for tags, but isn't checking out the correct code. It seems to be falling back to a newer branch (or master even?).
On contint1001 the files are from November 25th 2015 which is when 1.26.0 got released ( https://lists.wikimedia.org/pipermail/mediawiki-announce/2015-November/000184.html ).
I took a backup as /home/hashar/doc-mw-1.26.0.tar.gz and I am retriggering the build:
zuul enqueue-ref --trigger gerrit --pipeline publish --project mediawiki/core --ref refs/tags/1.26.0 --newrev 981ec62244e4806a16bda804dda1d14cb5d7f193
Oops, that was from an unrelated issue a few days back. Restored now.
I've re-re-triggered it. It seems to be working now.
Mentioned in SAL (#wikimedia-releng) [2017-04-11T08:55:48Z] <hashar> Retriggering MediaWiki doxygen publishing job for 1.26.0 - T162506 : zuul enqueue-ref --trigger gerrit --pipeline publish --project mediawiki/core --ref refs/tags/1.26.0 --newrev 981ec62244e4806a16bda804dda1d14cb5d7f193
mediawiki/core$ git rev-parse 1.26.0 981ec62244e4806a16bda804dda1d14cb5d7f193
In the job console, MediaWiki core seems to fetched at the appropriate revision:
DEBUG:zuul.Cloner:Fetched ref refs/tags/1.26.0 from mediawiki/core DEBUG:zuul.Repo:Checking out 981ec62244e4806a16bda804dda1d14cb5d7f193 INFO:zuul.Cloner:Prepared 'mediawiki/core' repo at revision '981ec62244e4806a16bda804dda1d14cb5d7f193'
Though for mediawiki/vendor that fall back to the master branch:
DEBUG:zuul.Repo:Updating repository src/vendor INFO:zuul.Cloner:Falling back to branch master DEBUG:zuul.Repo:Checking out remotes/origin/master INFO:zuul.Cloner:Prepared mediawiki/vendor repo with branch master at commit 24fbb91a8f6557d0cc0dce86b4c0a6b3533c586f
Most probably for Doxygen we could drop mediawiki/vendor entirely. I dont think it is needed.
I also connected on the instance that is running the build and the workspace point to the proper revision:
$ git show HEAD --decorate commit 365e22ee61035f953b47387af92ef832f09d5982 (HEAD, tag: 1.26.0) Author: Chad Horohoe <chadh@wikimedia.org> Date: Wed Nov 25 09:07:38 2015 -0800 Prep REL1_26 for general release Change-Id: Ia26f820c14891b97ee9a7c3cebf490273d8e6c7d
There is no match for makeKey().
So most probably we had a bug when the doc got generated back in November 2015
Potentially it could be that the tagging events is processed by Zuul before Gerrit managed to update the repo, and thus the job would not find the reference and fallback to the master branch. If that is correct, nowadays Zuul is always 5 seconds behind Gerrit to prevent that kind of race condition :(
https://doc.wikimedia.org/mediawiki-core/1.26.0/php/DefaultSettings_8php.html now shows $wgVersion = '1.26.0'.
Looking at all the other documentations, there are a lot of wrong ones:
contint1001$ (cd /srv/org/wikimedia/doc/mediawiki-core && grep --color=always --only-matching -R "\$wgVersion = '.*'" */php/DefaultSettings*|sort -n) 1.23.12/php/DefaultSettings_8php.html:$wgVersion = '1.27alpha' 1.23.13/php/DefaultSettings_8php.html:$wgVersion = '1.27alpha' 1.23.14/php/DefaultSettings_8php.html:$wgVersion = '1.28.0-alpha' 1.24.5/php/DefaultSettings_8php.html:$wgVersion = '1.27alpha' 1.24.6/php/DefaultSettings_8php.html:$wgVersion = '1.27alpha' 1.25.4/php/DefaultSettings_8php.html:$wgVersion = '1.27alpha' 1.25.5/php/DefaultSettings_8php.html:$wgVersion = '1.27alpha' 1.25.6/php/DefaultSettings_8php.html:$wgVersion = '1.28.0-alpha' 1.26.0/php/DefaultSettings_8php.html:$wgVersion = '1.26.0' 1.26.1/php/DefaultSettings_8php.html:$wgVersion = '1.27alpha' 1.26.2/php/DefaultSettings_8php.html:$wgVersion = '1.27alpha' 1.26.3/php/DefaultSettings_8php.html:$wgVersion = '1.28.0-alpha' 1.26.4/php/DefaultSettings_8php.html:$wgVersion = '1.28.0-alpha' 1.27.0/php/DefaultSettings_8php.html:$wgVersion = '1.27.0' 1.27.1/php/DefaultSettings_8php.html:$wgVersion = '1.27.1' 1.28.0/php/DefaultSettings_8php.html:$wgVersion = '1.28.0' 1.28.0-rc.0/php/DefaultSettings_8php.html:$wgVersion = '1.28.0-rc.0' 1.28.0-rc.1/php/DefaultSettings_8php.html:$wgVersion = '1.28.0-rc.1' master/php/DefaultSettings_8php.html:$wgVersion = '1.29.0-alpha' REL1_25/php/DefaultSettings_8php.html:$wgVersion = '1.25.6' REL1_26/php/DefaultSettings_8php.html:$wgVersion = '1.26.4' REL1_27/php/DefaultSettings_8php.html:$wgVersion = '1.27.1' REL1_28/php/DefaultSettings_8php.html:$wgVersion = '1.28.1'
I am regenerating the documentation for all 1.23.x releases (based on git show-ref --tags|grep tags/1.23|grep -v rc|gsort -t\. -k3 -n).
Retriggered doc for 1.27.2 and 1.28.1.
@Krinkle I guess we can delete the documentation for the legacy releases 1.24.x, 1.25.x, 1.26.x or do you think they should be regenerated as well? I dont even know whether those docs are actively used :(
I'd say having at least one for each of the major releases would be nice (preferably the latest patch release). We can remove the left-over ones we didn't regenerate that are presumably all broken.
We have all the patch releases for 1.23, 1.27 and 1.28.
I am dropping the ones for the EOL versions. That is:
Which are broken anyway.
And I have dropped the 1.28.0 release candidates. There is not much point in keeping doc for RC.
Thanks Timo!