In T411944#11438755, @Tacsipacsi wrote:

Thanks for caring about this! However, I’d say it’s a duplicate, as I think the scope of T411926: Patch Demo failed: no class Wikimedia\Equivset\Equivset is exactly the same – ensuring that wikimedia/equivset doesn’t get removed during various Composer operations.

In T411926#11438373, @IKhitron wrote:

In T411926#11438369, @Tacsipacsi wrote:

I tried, but the Patch Demo destroyed the wiki entirely, because I've fixed the patch after your comments, and it needs Jenkins bot approval.

That sounds like another bug: if you’re not allowed to update a patch demo, it should just not do anything, rather than destroying the existing patch demo…

You are absolutely right.

Tried adding a non-existent extension to extension-list in train-dev: went fine...maybe this has been a documentation problem for years?

CPU spike is a bunch of PHP processes running. PHP processes are running due to traffic, which spiked.

• Announcement banner for WikiFarms on Patchdemo.
• Send email about this addition too.

Adding an event on one wiki that is part of a wiki farm in Patch Demo, now shows up on the other wiki on "all events" where you can sign up!

(context: IRC discussion about possible releng ownership)

Hrm, thinking about this today, I realize the piece with the low-level metrics is running outside the daemon. So either way we'd need to get metrics from the batch jobs (e.g., scap sync-world) to some daemon. The PushGateway is probably the right place for this.

Is there another reason that we have the local lore that any extension or skin must be in all deployed branches before being added to wmf-config/extension-list?

Hrm. Well, SpiderPig does have a web daemon. That daemon doesn't persist any of the metric timings we used to track (as far as I'm aware). @dancy might be able to say something smarter than that about it :)

I was reminded of this task by T411474: Grafana "MW deploy" "Train deployments" annotations broken on some dashboards!

Do you know offhand if this require setting up a fluxx/WDQS within patch demo? Or are there test/dummy instances of those services already?

Looks like it hasn't happened since this instance. If we see this happen regularly, we should dig deeper. For now, I think we'll call this a fluke (i.e., a button was clicked at the same time as a task ran, maybe).

The busiest things on these nodes are php-fpm, so the wikis themselves.

In T407862#11409801, @thcipriani wrote:

It wouldn't let me delete REL1_43 due to open changes.

In T407862#11304903, @Samwilson wrote:

It looks like you have to have the Delete Reference right in Gerrit. I've just added that for myself on the Genealogy extension, and now I get the delete button next to all branches and can delete branches.

This is what the form looks like:

I assume there's some way to grant that right to the owners group, but it seems to only want a username in that field not a group name.

In T410442#11398796, @Salujapushpit wrote:

Hi, I’d like to kindly request permission to claim this task please let me know if it’s available.

Found something interesting in the logs that may or may not explain

In T409803#11384019, @A_smart_kitten wrote:

Verified in production by creating a new Patch Demo wiki that includes the WikimediaApiPortal skin - see screenshot below. (I suspect the lack of padding around the page content is probably part of how the skin works, rather than a bug in how it's been added to Patch Demo.) Thanks @jnuche for reviewing & merging!

In T306708#11394508, @Aklapper wrote:

• When did user login last with 2fa (I don't know, offhand how to get this)

We do not know because https://we.phorge.it/T16310

In T306708#11393919, @taavi wrote:

In T306708#11393904, @thcipriani wrote:

Proposed new verification option: ssh signatures

If an attacker has enough access to a developer account to get to the Phabricator 2FA screen, what's stopping them from just adding an another SSH key to that developer account and then using that key to "prove" they are the correct owner of said account?

Proposed new verification option: ssh signatures

Catalyst folks don't have time to pick this up this week. We'll leave it in backlog and come back to this in our next planning (unless someone beats us to it and we can review).

This is a nice to have change, not critical.

Thank you for tagging this task with good first task for Wikimedia newcomers!

Merged in T408830: Link to each wiki within a wikifarm from that wiki's main page since that was handled as part of this task.

Status:

• ci-charts changes ready for review, can merge ahead of UI changes independently
• UI changes mostly in MVP-shape, still needed: copy.php updates to support wikifarms
  • Everything aside from upcoming copy.php changes already reviewed.

Switchover will require maintenance window with downtime, @jnuche will announce some details on the patchdemo mailing list.

I am committed to merging this!

Love seeing a diff like this in a runbook: https://wikitech.wikimedia.org/w/index.php?title=Catalyst/Scaling&diff=prev&oldid=2361346

Might be as simple as adding it to the ./repository-lists/wikimedia.yaml file

Merged and deployed!

Noting here that Catalyst folks created this CI job, but are not planning to take action on this task since we're unsure how that CI variable controls browser version. @Peter are you planning on looking at this?

When you add a patch, the repo for that patch is not ticked, but if you click "Create" then that repo is checked out.

Hi all!