doc.wikimedia.org docs for old releases is actually master
Closed, ResolvedPublic

Description

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?).

Krinkle created this task.Apr 7 2017, 11:47 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 7 2017, 11:47 PM
Krinkle renamed this task from doc.wikimedia.org generates master branch docs with label of old release to doc.wikimedia.org docs for old releases is actually master.Apr 7 2017, 11:48 PM
hashar added a comment.EditedApr 10 2017, 10:12 AM

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

Looks like you have hacked the job :-]

echo 'Skipped! --Krinkle'
exit 1
Krinkle added a comment.EditedApr 10 2017, 11:19 PM

Looks like you have hacked the job :-]

echo 'Skipped! --Krinkle'
exit 1

Oops, that was from an unrelated issue a few days back. Restored now.

I am retriggering the build:

zuul enqueue-ref --trigger gerrit --pipeline publish --project mediawiki/core --ref refs/tags/1.26.0 --newrev 981ec62244e4806a16bda804dda1d14cb5d7f193

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 :(

@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.

hashar closed this task as Resolved.Apr 13 2017, 4:33 PM

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:

  • patch releases for 1.24, 1.25, 1.26
  • the related REL branches (REL1_ 19, 22, 24, 25, 26)

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!