Hello,
Yesterday I have updated the Jenkins jobs running PHPUnit to enable
$wgDebugLogFile and provide the result in the build result. That will
hopefully help people figuring what is wrong when a test is failing.
As an example, the VisualEditor extension as a qunit job. It uses
phantomjs (a
Hello,
I will be upgrading Jenkins tomorrow at 8:00UTC for a minor upgrade.
The upgrade should take roughly one hour, during that time any job
launched will be reported as LOST in Gerrit and would need to be
retriggered manually (by editing the commit summary for example).
Thanks!
--
Antoine
Hello,
Too long, dont want to read:
https://integration.wikimedia.org/cover/mediawiki-core/master/php/
Jenkins is nowadays producing a nightly coverage report. The idea is to
run our full PHPUnit tests, track which lines in MediaWiki core have
been executed and show up metrics regarding code
:D
On 18 October 2013 10:09, Antoine Musso hashar+...@free.fr wrote:
Hello,
Yesterday I have updated the Jenkins jobs running PHPUnit to enable
$wgDebugLogFile and provide the result in the build result. That will
hopefully help people figuring what is wrong when a test is failing.
As an
On Fri, Oct 18, 2013 at 5:52 AM, Antoine Musso hashar+...@free.fr wrote:
track which lines in MediaWiki core have been executed
Does it count the whole line as covered for something like
$var = $alwaysTrue ? $something : $something_else;
or just the true case?
In June I enforced a PHPUnit
On Fri, Oct 18, 2013 at 8:23 AM, Brad Jorsch (Anomie) bjor...@wikimedia.org
wrote:
On Fri, Oct 18, 2013 at 5:52 AM, Antoine Musso hashar+...@free.fr wrote:
In June I enforced a PHPUnit feature which force us to mention which
MediaWiki function is covered by a test method [FORCE COVER].
On Fri, Oct 18, 2013 at 12:13 PM, Erik Bernhardson
ebernhard...@wikimedia.org wrote:
On Fri, Oct 18, 2013 at 8:23 AM, Brad Jorsch (Anomie) bjor...@wikimedia.org
wrote:
On Fri, Oct 18, 2013 at 5:52 AM, Antoine Musso hashar+...@free.fr wrote:
In June I enforced a PHPUnit feature which force
different definitions of test ;-) code touched seems like a much less
useful metric than code specifically tested, but i could be convinced
otherwise.
On Fri, Oct 18, 2013 at 9:31 AM, Brad Jorsch (Anomie) bjor...@wikimedia.org
wrote:
On Fri, Oct 18, 2013 at 12:13 PM, Erik Bernhardson
2013/10/18 Antoine Musso hashar+...@free.fr:
Hello,
Too long, dont want to read:
https://integration.wikimedia.org/cover/mediawiki-core/master/php/
This is very cool, apart from the numbers of course.
Is it hard to setup for extensions as well? Lots of development
happens in extensions
Hey,
Thanks for setting this up hashar! It's a very useful metric to have.
I'd like to bring some attention to the dashboard link at the top of
coverage pages, which leads to for instance
https://integration.wikimedia.org/cover/mediawiki-core/master/php/index.dashboard.html
This page is very
True, but there's two sides of this.
When needing the explicit annotation, it will keep out stuff that shouldn't be
included (I agree on the wfRunHooks example).
However, depending on how it's implemented, it might also remove the very
essence of line coverage. We wouldn't want to disable
On 10/18/2013 05:23 PM, Brad Jorsch (Anomie) wrote:
On Fri, Oct 18, 2013 at 5:52 AM, Antoine Musso hashar+...@free.fr wrote:
track which lines in MediaWiki core have been executed
Does it count the whole line as covered for something like
$var = $alwaysTrue ? $something : $something_else;
On 10/18/2013 05:52 AM, Antoine Musso wrote:
Hello,
Too long, dont want to read:
https://integration.wikimedia.org/cover/mediawiki-core/master/php/
Uh, what does test coverage on tests/ directory even mean? Who
swatches the watchers/s tests the tests?
— Victor.
Hey,
Uh, what does test coverage on tests/ directory even mean? Who
swatches the watchers/s tests the tests?
Good point. Non-production code typically ought to be excluded. This is
pretty simple to do with some PHPUnit config:
In one of the earlier discussions about revising the deletion schema,
Happy-Melon pointed out, Right now everyone who has ideas for *an*
implementation isn't working on it because they don't know if it's *the*
implementation we want. It seems to me that if one proposal is clearly
superior, we
Thank you!
On 10/18/2013 11:52 AM, Antoine Musso wrote:
Now I am wondering where on mw.org I can document our coverage system.
Should we get a page under [[Continuous integration]] or maybe another
section in [[Manual:PHP unit testing]] ??
Its specific to PHPUnit so I went ahead and added
Le 18/10/13 10:41, Antoine Musso a écrit :
I will be upgrading Jenkins tomorrow at 8:00UTC for a minor upgrade.
It is not tomorrow (which is a saturday) but definitely on Monday 21st
as stated in the message subject and on the deployment schedule.
Sorry :)
On 10/18/2013 07:31 PM, Jeroen De Dauw wrote:
Uh, what does test coverage on tests/ directory even mean? Who
swatches the watchers/s tests the tests?
Good point. Non-production code typically ought to be excluded. This is
pretty simple to do with some PHPUnit config:
Le 18/10/13 19:20, Jan Zerebecki a écrit :
The whole line. This is a limitation of the PHP extension Xdebug. See
http://phpunit.de/manual/current/en/code-coverage-analysis.html#code-coverage-analysis.edge-cases
Based on my experience, there will also be some false negatives.
And also note
Le 18/10/13 18:42, Niklas Laxström a écrit :
Too long, dont want to read:
https://integration.wikimedia.org/cover/mediawiki-core/master/php/
This is very cool, apart from the numbers of course.
Is it hard to setup for extensions as well? Lots of development
happens in extensions
Le 18/10/13 18:52, Jeroen De Dauw a écrit :
Hey,
Thanks for setting this up hashar! It's a very useful metric to have.
I'd like to bring some attention to the dashboard link at the top of
coverage pages, which leads to for instance
Hey,
For those interested in having coverage reports for their extensions, you
can look at the source of any of the extensions listed here:
https://coveralls.io/r/wikimedia
These extensions allow running their tests by executing phpunit in their
root directory. That makes creating the coverage
Le 18/10/13 20:18, Jan Zerebecki a écrit :
Its specific to PHPUnit so I went ahead and added
https://www.mediawiki.org/wiki/Manual:PHP_unit_testing/Writing_unit_tests#Coverage
Excellent! And I think that is the first time ever I validate a diff on
mediawiki.org \O/
Thank you!
--
Antoine
Mobile is definitely interested in running this for MobileFrontend. I'll
read up as well.
On Fri, Oct 18, 2013 at 1:34 PM, Antoine Musso hashar+...@free.fr wrote:
Le 18/10/13 18:42, Niklas Laxström a écrit :
Too long, dont want to read:
Le 18/10/13 16:04, addshorewiki a écrit :
On 18 October 2013 10:09, Antoine Musso wrote:
Yesterday I have updated the Jenkins jobs running PHPUnit to enable
$wgDebugLogFile and provide the result in the build result. That will
hopefully help people figuring what is wrong when a test is
The Wikimedia Foundation's Technical Operations team is seeking proposals on
the provisioning of a new data-centre facility.
After working through the specifics internally, we now have a public RFP
posted[1] and ready for proposals. We invite any organization meeting the
requirements outlined
Hi, would you be open to a data center outside the US in future, and if no,
why not?
Rupert
Am 18.10.2013 22:05 schrieb Ken Snider ksni...@wikimedia.org:
The Wikimedia Foundation's Technical Operations team is seeking proposals
on the provisioning of a new data-centre facility.
After working
Hi Rupert,
We'd be open to any jurisdiction that provides an appropriate legal foundation
for our operations, as well as meeting our technical and topographic needs.
However for this specific proposal, we're looking for a US-centric location
that can serve as a backup should our Ashburn
Hi folks,
after speaking to a few folks, I'd like to check in on the WMF deployment
train schedule overall, and see if there are ways to optimize it.
(Note: In the below I refer to test wikis vs. production wikis,
generously including mediawiki.org as a test wiki. I realize that our test
wikis,
Hello and welcome to the lastest and greatest deploy highlights email,
this time for the week of October 21st.
== Highlights of the week ==
On Tuesday October 22nd, Echo (Notifications) will be doing it's final
major release. The wikis included are listed here:
On 18 October 2013 15:26, Erik Moeller e...@wikimedia.org wrote:
Hi folks,
after speaking to a few folks, I'd like to check in on the WMF deployment
train schedule overall, and see if there are ways to optimize it.
[Snip]
I think Option B is a good option, and agree that it's a good
In one week, we (Markus Glaser and I) plan to create a REL1_22 branch
for the 1.22.0 that we have scheduled for 6 weeks from now, no later
than November 29th.
In order to facilitate this, please make sure anything you want in 1.22
is ready this week. We'll probably do a couple merges from the
Hi Erik,
I'm not a fan of removing one of the stages of our current deployments.
More inline:
On Fri, Oct 18, 2013 at 3:26 PM, Erik Moeller e...@wikimedia.org wrote:
Option B: No Monday deploy. This would mean we'd have to improve our
testing process to catch issues affecting the
Rob Lanphier wrote:
Option C: Shift Monday deploys to Tuesday. This would at least give us
an additional work day to fix issues that have occurred in testing before
they hit prod. I personally don't think this goes far enough, but might
be a useful tweak to make if option B seems too problematic.
On Fri, Oct 18, 2013 at 6:41 PM, MZMcBride z...@mzmcbride.com wrote:
Rob Lanphier wrote:
Option C: Shift Monday deploys to Tuesday. This would at least give us
an additional work day to fix issues that have occurred in testing before
they hit prod. I personally don't think this goes far
35 matches
Mail list logo
