ActivePublic

Actions

If you've submitted patches for MediaWiki core, skins or extensions, you've seen this output in Gerrit:

Our code review system Gerrit has several caches, the largest ones being backed up on disk. The disk caches offload memory usage and persist the data between restarts. As a Java application, the caches are stored in H2 database files and I recently had to find how to connect to them in order to inspect their content and reduce their size.

Mediawiki developers, have you ever thought, “I wish I could deploy my own code for Mediawiki”? Now you can! More deploys! More fun!

How are we doing in our strive for operational excellence? Read on to find out!

How are we doing in our strive for operational excellence? Read on to find out!

How’d we do in our strive for operational excellence last month? Read on to find out!

Release Engineering's "GitLab-a-thon" sprint for May 10th-24th (roughly) focused on the mechanics of migrating a Wikimedia service to GitLab, setting up a CI pipeline, building container images from that service, and publishing images to the Wikimedia registry. We selected the Blubber project as a good candidate for experimentation:

How’d we do in our strive for operational excellence last month? Read on to find out!

How’d we do in our strive for operational excellence last month? Read on to find out!

Developers should own the process of putting their code into production. They should decide when to deploy, monitor their deployment, and make decisions about rollback.

Over here in the Release-Engineering-Team, Train Deployment is usually a rotating duty. We've written about it before, so I won't go into the exact process, but I want to tell you something new about it.

How’d we do in our strive for operational excellence last month? Read on to find out!

I'll start with a bit of general administrivia. First, our migration of Wikimedia code review & CI to GitLab continues, and we're mindful that people could use regular updates on progress. Second, I need to think through some stuff about the project, and doing that in writing is helpful for all involved. I'm going to try writing occasional blog entries here for both purposes.

If you’ve ever experienced the pride of seeing your name on MediaWiki's contributor list, you've been involved in our deployment process (whether you knew it or not).

How’d we do in our strive for operational excellence last month? Read on to find out!

How’d we do in our strive for operational excellence last month? Read on to find out!

How’d we do in our strive for operational excellence last month? Read on to find out!

How’d we do in our strive for operational excellence last month? Read on to find out!

This post gives a quick introduction to a benchmarking tool, phpbench, ready for you to experiment with in core and skins/extensions.[1]

How’d we do in our strive for operational excellence last month? Read on to find out!

Last week I spoke to a few of my Wikimedia Foundation (WMF) colleagues about how we deploy code—I completely botched it. I got too complex too fast. It only hit me later—to explain deployments, I need to start with a lie.

How’d we do in our strive for operational excellence last month? Read on to find out!

How’d we do in our strive for operational excellence last month? Read on to find out!

How’d we do in our strive for operational excellence last month? Read on to find out!

The release engineering team triages tasks flagged Release-Engineering-Team on a weekly basis. It is an all hands on deck one hour meeting in which we pick tasks one by one and find out what to do with them. We have started with more than a hundred of them and are now down to just a dozen or so, most filed since the last meeting.

How’d we do in our strive for operational excellence last month? Read on to find out!

How’d we do in our strive for operational excellence last month? Read on to find out!

How’d we do in our strive for operational excellence last month? Read on to find out!

One of the critical pieces of our infrastructure is Gerrit. It hosts most of our git repositories and is the primary code review interface. Gerrit is written in the Java programming language which runs in the Java Virtual Machine (JVM). For a couple years we have been struggling with memory issues which eventually led to an unresponsive service and unattended restarts. The symptoms were the usual ones: the application responses being slower and degrading until server side errors render the service unusable. Eventually the JVM terminates with:

How’d we do in our strive for operational excellence last month? Read on to find out!

How’d we do in our strive for operational excellence last month? Read on to find out!

How’d we do in our strive for operational excellence last month? Read on to find out!

How’d we do in our strive for operational excellence last month? Read on to find out!

Recently there has been a small effort on the Release-Engineering-Team to encode some of our institutional knowledge as runbooks linked from a page in the team's wiki space.

How’d we do in our strive for operational excellence last month? Read on to find out!

How’d we do in our strive for operational excellence last month? Read on to find out!

If you're making changes to a service that is deployed to Kubernetes, it sure is annoying to have to update the helm deployment-chart values with the newest image version before you deploy. At least, that's how I felt when developing on our dockerfile-generating service, blubber.

How’d we do in our strive for operational excellence last month? Read on to find out!

How’d we do in our strive for operational excellence last month? Read on to find out!

In 2015 I noticed git fetches from our most active repositories to be unreasonably slow, sometimes up to a minute which hindered fast development and collaboration. You can read some of the debugging details I have conducted at the time on T103990. Gerrit upstream was aware of the issue and a workaround was presented though we never went to implement it.

How’d we do in our strive for operational excellence last month? Read on to find out!

Earlier today, the 600,000th commit was pushed to Wikimedia's Gerrit server. We thought we'd take this moment to reflect on the developer services we offer and our community of developers, be they Wikimedia staff, third party workers, or volunteers.

How are we doing on that strive for operational excellence during these unprecedented times?

How’d we do in our strive for operational excellence last month? Read on to find out!

How’d we do in our strive for operational excellence last month? Read on to find out!

How’d we do in our strive for operational excellence in November and December? Read on to find out!

How’d we do in our strive for operational excellence last month? Read on to find out!

How’d we do in our strive for operational excellence last month? Read on to find out!

In Changes and improvements to PHPUnit testing in MediaWiki, I wrote about efforts to help speed up PHPUnit code coverage generation for local development.[0] While this improves code coverage generation time for local development, it could be better.

This past week marks the release of a little tool that I've been working on for a while. In fact, it's something I've wanted to build for more than a year. But before I tell you about the solution, I need to describe the problem that I set out to solve.

How’d we do in our strive for operational excellence in August? Read on to find out!

How’re we doing on that strive for operational excellence? Read this first anniversary edition to find out!

How’d we do in our strive for operational excellence last month? Read on to find out!

Building off the work done at the Prague Hackathon (T216260), we're happy to announce some significant changes and improvements to the PHP testing tools included with MediaWiki.

How’d we do in our strive for operational excellence last month? Read on to find out!

How’d we do in our strive for operational excellence last month? Read on to find out!

After many months of discussion, work and consultation across teams and departments[0], and with much gratitude and appreciation to the hard work and patience of @thcipriani and @hashar, the Code-Health-Metrics group is pleased to announce the introduction of the code health pipeline. The pipeline is currently in beta and enabled for GrowthExperiments, soon to be followed by Notifications, PageTriage, and StructuredDiscussions. (If you'd like to enable the pipeline for an extension you maintain or contribute to, please reach out to us via the comments on this post.)

How’d we do in our strive for operational excellence last month? Read on to find out!

Writing blog is neither my job nor something that I enjoy, I am thus late in the Quibble updates. The last one Blog Post: Quibble in summer has been written in September 2018 and I forgot to publish it until now. You might want to read it first to get a glance about some nice changes that got implemented last summer.

Note: this post has been published on 03/28 but has been originally written in September 2018 after Quibble 0.0.26 and never got published.

The working group to consider future CI tooling for Wikimedia has finished and produced a report. The report is at https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/CI_Futures_WG/Report and the short summary is that the release engineering team should do prototype implementations of Argo, GitLab CI/CD, and Zuul v3.

How’d we do in our strive for operational excellence? Read on to find out!

For a few weeks, a CI job had PHPUnit tests abruptly ending with:

The working group to consider future tooling for continuous integration is making progress (see previous blog post J148 for more information). We're looking at and evaluating alternatives and learning of new needs within WMF.

The Release Engineering team has started a working group to discuss and consider our future continuous integration tooling. Please help!

How’d we do in our strive for operational excellence last month? Read on to find out!

How’d we do in our strive for operational excellence last month? Read on to find out!

1. Code Health

How’d we do in our strive for operational excellence last month? Read on to find out!

How’d we do in our strive for operational excellence last month? Read on to find out!

The Release Engineering team wants to continually improve the quality of our software over time. One of the ways in which we hoped to do that this year is by creating more useful Selenium smoke tests. (From now on, test will be used instead of Selenium test.) This blog post is about how we determined where the tests should focus and the relative priority.

Halloween is a full two weeks behind us here in the United States, but it's still on my mind. It happens to be my favorite holiday, and I receive it both gleefully and somberly.

How’d we do in our strive for operational excellence last month? Read on to find out!

This blog post will describe a bit about how we are utilizing the "Task Types" feature in Phabricator to facilitate better tracking of work and to streamline workflows with custom fields. Additionally, I will be soliciting feedback about potential use-cases which could potentially take further advantage of this feature.

It has been a while since the last mediawiki_selenium release! 💎

[Quibble] is the new test runner for MediaWiki (see the intro Blog Post: Introducing Quibble). This post is to give an update of what happened during May 2018.

One particularly interesting topic discussed during the Hackathon Technical Debt session (T194934) was that of the contagious aspect of technical debt. Although this makes sense in hindsight, it's not something that I had really given much thought to previously.

Dependencies are Git Python 3, and Docker Community Edition (CE).

Running all tests for MediaWiki and matching what CI/Jenkins is running has been a constant challenge for everyone, myself included. Today I am introducing Quibble, a python script that clone MediaWiki, set it up and run test commands.

I have been working on the project with more or less focus on it since 2015. Maybe the easiest way to follow the project is by taking a look at a few epic tasks:

This is a digest of the updates from several weeks of changelogs which are published upstream. This is an incomplete list as I've cherry-picked just the changes which I think will be of significant interest to end-users of Wikimedia's phabricator. Please see the upstream changelogs for a detailed overview of everything that's changed recently.

This is your friendly but final warning that we are replacing Selenium tests written in Ruby with tests in Node.js. There will be no more reminders. Ruby stack will no longer be maintained. For more information see T139740 and T173488.

Željko Filipin, Engineer (Contractor) from Release Engineering team. That's me! 👋

Originally an email sent on September 25 2017 to qa, engineering and wikitech-l mailing lists.

Originally an email sent on August 23 2017 to qa, engineering and wikitech-l mailing lists.

Originally an-email sent on April 3 2017 to qa, engineering and wikitech-l mailing lists.

I just finished deploying an update to Phabricator which includes a simple but rather useful feature:

In T135327, the WMF Technical Collaboration team collected a list of Phabricator bugs and feature requests from the Wikimedia Developer Community. After identifying the most promising requests from the community, these were presented to Phacility (the organization that builds and maintains Phabricator) for sponsored prioritization.

Starting Thursday May 12th, 13:00 PDT ( 20:00 GMT ) we will be having the first weekly Code Review office hours on freenode IRC in the #wikimedia-codereview channel.

Not a lot has changed for Wikimedia's instance of Phabricator over the past few months. That's because a lot has been happening behind the scenes, as well as upstream at Phacility. Members of the Release-Engineering-Team and Team-Practices group have been working since December 2015 to integrate various upstream changes, however, nothing was released to our production instance because there were so many important features that were in-progress and not yet fully usable. Additionally, we had to figure out exactly how these features would fit with the specific needs of our project and test a lot of functionality to be sure that we would not break anyone's workflows.