The alarm got removed via https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/550943/ for some reason ...

Note that JJB 3.0.x does not enforce it.

That went well overall, we got some useful feedback and calls for actions.

In Quibble the composer update is run from the root of mediawiki/core which then uses the composer merge plugin which process the extension installation. I would guess the issue is that either the update done via the plugin is not bubbled up properly to the composer command or maybe its Quibble shallowing it.

It might be that this test is flapping / unreliable or has some kind of time based race condition?

There are some technical details at T224285#5216226

In T238055#5656328, @awight wrote:

I think the confusion is caused by a late failure. The original error is from composer install, where one dependency requires wikimedia/assert:v0.4.0, and then wikibase-lexeme requires wikimedia/assert ([>= 0.2.2.0-dev < 0.3.0.0-dev]). Composer reports,

14:48:37 [500.2MB/9.66s] Your requirements could not be resolved to an installable set of packages.
14:48:37 [500.2MB/9.66s] 
14:48:37   Problem 1
14:48:37     - The requested package wikimedia/assert ~0.2.2 is satisfiable by wikimedia/assert[v0.2.2] but these conflict with your requirements or minimum-stability.

This should have immediately crashed the build. Instead, we start installing MediaWiki and run into missing classes caused by incomplete PHP libs installation.

And I have marked it read-only in Gerrit https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/TimezoneSelector

I have abandoned a change was still opened https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/TimezoneSelector/+/422202/

I thought I could reuse the releng/quibble-stretch-php72 container but it lacks pip to do the installation, though it has easy_install through setuptools. Maybe that is sufficient to install Quibble from a local clone/fetch.

(comment best seen via the web interface)

In T224448#5650235, @Paladox wrote:

Interestingly this may have been a kernel bug: https://gerrit-review.googlesource.com/c/gerrit/+/153090/4#message-10cc8f42c24c28b1cb29c441c9aff13684555654
So when we upgraded to buster, that came with a new kernel that included the fix!

10/10 totally aced.

Assuming that got fixed somewhere :]

You guys are amazing. As soon as the extras field is not needed anymore, lets definitely clear it up from the CI phan shell scripts :]

I am not active on the Phan front, but could we imagine upgrading Phan in our release branches toward 0.8 to get rid of that extra in composer.json? It might be possible simply by adding some ignore/exclude for newly introduced rules we probably do not want to fix in release branches.

Out of the TODO queue; It is upstreamed and not a priority.

In T234224#5536925, @Osnard wrote:

Yes, I actually want to push instead of review, as I just want to synchronize branches REL1_31 and REL1_31_dev. In REL1_31_dev everything has already been reviewed, so I don't want to review all those commits again when merging them into REL1_31. I believe the above workflow works just fine. The only issue is the Push permission. But there is a solution now.

I guess that would address a feature I have listed T209463 namely for each task add a link to a Gerrit search query for bug:Txxxx ( https://gerrit.wikimedia.org/r/#/q/bug:T12345 ) :] I have marked it as a duplicate of your task :]

@kostajh and I had several exchanges and we even prepared a quick slide deck. Seems we orient ourselves toward:

The long story is at T235715#5588924

The issue we had should be addressed by:

The bot is less active in the recent days. We have upgraded the Gerrit server meanwhile and have lot more memory allocated to the JVM.

Awesome, thank you for the backport to REL1_34!

There are two issues:

I did, that was in a sub task blocking this change.

Really that is unfair, when all that was needed is to simply rebuild the Jessie base image :-\

the rsyslog package is broken on jessie and nobody care. The workaround to use when building a jessie instance is T222166#5147045

apt install rsyslog rsyslog-gnutls ; apt install rsyslog rsyslog-gnutls

In T228346#5640457, @Jdforrester-WMF wrote:

In T228346#5639754, @hashar wrote:

Else I guess this task can be closed with the resolution being PHP 7.2.22.

In that case, should we bump the minimum version the MW requires to 7.2.22? Would be good to decide this before 1.34.0 final ships.

Before 3.1.0:

$ time ./utils/jjb-diff.sh
real	1m25,691s
user	1m22,462s
sys	0m1,487s

@Andrew @bd808 @aborrero can you look at updating the bios setting for some of the affected cloudvirt?

All the builds since last capture:

I guess I can do some profiling using perf record for both case and hope that perf diff would shows anything standing up. Else I guess I would attempt to bisect the affected Docker version. Then 18.06 -> 18.09 is a major change, 18.06 had the Docker daemon spawning the containers while 18.09 delegates that to containerd.io which is managed by systemd.

Whenever changes have been to the repository (see https://gerrit.wikimedia.org/r/#/q/project:labs/tools/discordwiki
), it is indeed better to archive the repository. Else all the review comments, approvals etc are lost :]

Thank you @Joe. From CI containers perspective adding a var_dump( 'PHP_VERSION' ); to Tim script:

$ cat fail.php|docker run --entrypoint=php --rm -i docker-registry.wikimedia.org/releng/php72:0.2.2-s1
string(53) "7.2.16-1+0~20190307202415.17+stretch~1.gbpa7be82+wmf1"
object(C)#2 (1) {
  ["p"]=>
  object(stdClass)#1 (1) {
    ["x"]=>
    array(1) {
      ["p"]=>
      *RECURSION*
    }
  }
}

$ cat fail.php|docker run --entrypoint=php --rm -i docker-registry.wikimedia.org/releng/php72:0.2.2-s2
string(47) "7.2.22-1+0~20190902.26+debian9~1.gbpd64eb7+wmf1"
object(C)#2 (1) {
  ["p"]=>
  object(stdClass)#1 (1) {
    ["x"]=>
    array(0) {
    }
  }
}

The error now more shows up since the cleaning has been disabled behind a feature flag by https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/502316/

The heap size has been grown from 20G to 32G ( https://gerrit.wikimedia.org/r/545381 )

Well done Tyler thank you :]

Github had a feature to declare a repository has being a mirror but it can no more be used. There is a hint at https://help.github.com/en/github/getting-started-with-github/finding-open-source-projects-on-github#open-source-projects-with-mirrors-on-github and an example is chromium/chromium:

That fix it for master but the release branches would face the same issue. The CI containers are the same for all branches and thus all include wikidiff2.
We might have to backport $wgDiffEngine to our previous releases (REL1_31, REL1_32 and REL1_33).

Thank you @Dzahn for all the clean up tasks!

https://doc.wikimedia.org/ updated. Thank you!

In T164296#3235366, @hashar wrote:

My Jenkins issue was a duplicate of https://issues.jenkins-ci.org/browse/JENKINS-43438 which got fixed! Commit is https://github.com/jenkinsci/performance-plugin/commit/2d298b24e9761a8ff3d6e39c6f525f612f68829f

I thought about using spicerack written by volans but that is a different use case. The outcome of the discussion is probably that we should use scap to populate our deployment scripts and then just shell out to run those scripts. So eg:

ssh contint1001.wikimedia.org ci-deploy-docker

@tstarling did fill https://bugs.php.net/bug.php?id=78379 and some commits are in PHP 7.2.22 (see my previous comment T228346#5491809).

I have marked the build to be kept for ever https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php72-docker/28791/ in the build artifacts there is mw-error.log which has errors such as:

Once api-testing is made a npm package, each extension interested in having such tests would add the module to its package.json. Then we can establish a convention that there must be npm script defined. Quibble can then process each extension and run the suite if that script is present.

$wgExternalDiffEngine defaults to false which also mean it would first use wikidiff2 when the function wikidiff2_do_diff is detected. There is no way to force the php native one :-\

Yes, try it and see whether we can parse them with the Jenkins Collapsible plugin :]

Both changes got merged. Pending release.

Did a recheck and Awight even +2ed both patches:

That has been broken since October 15th due to https://gerrit.wikimedia.org/r/#/c/integration/config/+/543170/2/jjb/php-extensions.yaml which supposedly should have changed the job to use an image with php 7.2.22 but the image version is wrong.

I had the issue on my local machine (php7.3). I have just run composer install ./vendor/bin/phpunit --coverage-clover clover.xml.

I have rebuild the container, updated a job, ran perf top -g -p on the php process. getpid() is gone \o/

• the CI instances are back to Docker 18.06.2
• the job uses a container with an updated xdebug ( docker-registry.wikimedia.org/releng/quibble-coverage:0.0.39-s3 )

All good thank you @jijiki !

Gotta rebuild the CI containers and switch jobs to it ;]

So I have downloaded https://people.wikimedia.org/~jiji/php-xdebug_2.7.0-1+wmf2_amd64.deb

Well actually it is due to the PHPUnit 6 upgrade which has been done by 6edf7d939f499137e40aab1aca2739ce5ce4d805

Phabricator edit conflict. @jijiki is indeed working on it :]

I guess we want:

# If the EXTRACT_ALL tag is set to YES, doxygen will assume all entities in
# documentation are documented, even if no documentation was available. Private
# class members and static file members will be hidden unless the
# EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES.
# Note: This will also disable the warnings about undocumented members that are
# normally produced when WARNINGS is set to YES.
# The default value is: NO.

Heading to docs/php/namespaces.html that shows:

Wikibase	
  Lib	-file-suppress PhanTypeInvalidThrowsIsInterface
  Repo
    Specials	
      HTMLForm	-file-suppress PhanParamSignatureMismatch The point of this class is to change signatures